JP5597230B2

JP5597230B2 - 情報操作装置、情報出力装置および情報操作プログラム

Info

Publication number: JP5597230B2
Application number: JP2012181021A
Authority: JP
Inventors: 井遵金; 崎宏磯
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2012-08-17
Filing date: 2012-08-17
Publication date: 2014-10-01
Anticipated expiration: 2032-08-17
Also published as: JP2014038245A; US9608966B2; US20140052986A1

Description

本発明の実施形態は、機器操作命令の送受を行う情報操作装置、情報出力装置および情報操作プログラムに関する。

近年、スマートフォンやタブレット等の情報操作端末とＴＶをインタフェースを介して接続し、ＴＶを操作する技術がある。

特開2005-149205号公報

本実施形態は、ユーザの許諾なしに情報出力装置が勝手に操作されることを防止しつつ、情報操作装置から情報出力装置を操作できるようにして利便性を向上させた情報操作装置、情報出力装置および情報操作プログラムを提供するものである。

本実施形態によれば、第１通信装置からウェブアプリケーションを取得するための接続確立処理を行い、前記ウェブアプリケーションを受信する第１コネクション部と、前記第１コネクション部を介して前記第１通信装置から受信した前記ウェブアプリケーションを実行して機器操作命令を生成するウェブアプリ実行部と、ウェブアプリケーションから認証要求を受けると、前記第２通信装置に認証要求を送信するとともに、これに応答して前記第２通信装置から送信された認証要求子を受信するための接続確立処理を行い、認証要求子を受信する第２コネクション部と、前記第２コネクション部を介して前記第２通信装置から受信した前記認証要求子を、前記第２通信装置との間で共有する共通鍵に基づいて暗号化したプラットホーム認証子を生成するアプリ認証処理部と、前記プラットホーム認証子に前記ウェブアプリケーションの出所情報を付与するアプリ出所情報付与部と、前記第２通信装置に、前記機器操作命令と前記出所情報が付与されたプラットホーム認証子とを送信するための接続確立処理を行い、前記機器操作命令と前記出所情報が付与されたプラットホーム認証子とを送信する第３コネクション部と、を備えることを特徴とする情報操作装置が提供される。

情報処理システム４の全体構成の一例を示すブロック図。第１の実施形態における情報操作装置１の内部構成を示すブロック図。 Webアプリ実行部２１とアプリ認証処理部２３の内部構成を示すブロック図。第１の実施形態における情報出力装置３の内部構成を示すブロック図。第１の実施形態におけるWebアプリ配布サーバ５の内部構成を示すブロック図。 Webアプリ実行部２１とアプリ認証処理部２３の起動時のフローチャート。認証要求命令検知時の処理手順の一例を示すフローチャート。情報出力装置３への機器操作命令の送信手順の一例を示すフローチャート。認証要求受信時の情報出力装置３の処理手順の一例を示すフローチャート。第３のコネクション確立要求時の情報出力装置３の処理手順のフローチャート。情報操作装置１と情報出力装置３の処理手順の一例を示すシーケンス図。第２の実施形態における情報操作装置１の内部構成の一例を示すブロック図。許可出所リスト１０のデータ構造の一例を示す図。認証要求命令検出時の処理手順の一例を示すフローチャート。第３の実施形態における情報操作装置１の内部構成の一例を示すブロック図。第３の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図。許可出所リスト更新の処理手順の一例を示すフローチャート。第４の実施形態における情報操作装置１の内部構成の一例を示すブロック図。第４の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図。認証要求命令検出時の処理手順の一例を示すフローチャート。第５の実施形態における情報操作装置１の内部構成を示すブロック図。第５の実施形態における認証要求命令検出時の処理手順を示すフローチャート。第６の実施形態における情報処理装置の内部構成を示すブロック図。第６の実施形態における認証要求命令検出時の処理手順を示すフローチャート。第７の実施形態における情報処理装置の内部構成を示すブロック図。鍵番号、鍵有効性および鍵情報の対応関係を登録したテーブルを示す図。第７の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図。第７の実施形態における情報出力装置３の内部構造を示すブロック図。リボーク処理を含む認証要求時の処理手順を示すフローチャート。第７の実施形態における鍵更新時の処理手順を示すフローチャート。

以下、図面を参照しながら、本発明の一実施形態を説明する。

（第１の実施形態）
図１は情報操作装置１からネットワーク２経由で機器操作命令を送信して情報出力装置（第２通信装置）３を遠隔操作する情報処理システム４の全体構成の一例を示すブロック図である。図１の情報処理システム４は、ウェブアプリケーションをサーバから受信して遠隔機器操作命令を含むプログラムを実行する情報操作装置１と、映像等を表示する情報出力装置３と、アプリケーションを配布するWebアプリ配布サーバ（第１通信装置）５とを備えている。情報操作装置１とWebアプリ配布サーバ５はインターネット等のネットワーク２で接続され、同様に、情報操作装置１と情報出力装置３もネットワーク２で接続され、ネットワークインタフェースを介して情報の送受を行う。ここで、ウェブアプリケーションの構成部品であるページファイルやメディアファイルは、サーバ（Webアプリ配布サーバ５）上で管理され、URL（Uniform Resource Locator）と呼ばれる位置識別子で格納位置が特定される。

情報操作装置１は、共通のバス１１に接続された、CPU１２、主記憶１３、ディスプレイ１４、入力機器１５、ネットワークインタフェース部１６、およびストレージ部１７を有する。入力機器１５は、マウス、キーボード、およびタッチパネル等である。ストレージ部１７は、ウェブアプリケーション（Webアプリ）とプラットホームアプリケーション（以下、PFアプリ）を格納している。WebアプリはWebアプリ実行部２１で実行され、PFアプリはPFアプリ実行部（アプリ認証処理部２２）で実行される。Webアプリの内部には、ソフトウエアモジュールである、IPコネクション管理部２４、入力受信部２５、HTTP処理部２６およびアプリ出所付与部２７が含まれている。

情報出力装置３は、ネットワークインタフェース部３１と、情報操作装置１から送信された機器操作命令を処理する機器操作命令処理部３２とを有する。

Webアプリ配布サーバ５は、ネットワークインタフェース部４１と、ストレージ部４２とを有する。ストレージ部４２には、後述するように、ページファイル４２ａとメディアファイル４２ｂが格納される。

情報操作装置１でWebアプリを実行する際には、下準備として、Webアプリの実行環境であるアプリ実行部プログラムの実行を行う。この際、情報操作装置１のCPU１２で実行されているOSなどのシェルプログラムがユーザの要求等に従い、アプリ実行部プログラムを情報操作装置１内のストレージ部から読み取る。また、CPU１２は読み取ったアプリ実行部プログラムを主記憶１３に保存し、アプリ実行部プログラムを実行する。

Webアプリは、ユーザもしくはプログラムにてページファイルのURLを指定することにより実行開始される。その際、CPU１２はネットワークインタフェース部１６に対して指定URLのページファイルの取得命令を出す。ネットワークインタフェース部１６は指定URLのサーバに接続し、該当ファイルのダウンロード命令を発行する。

Webアプリ配布サーバ５のネットワークインタフェース部４１はストレージ部４２から該当ファイルを読み取って情報操作装置１に返信する。情報操作装置１のネットワークインタフェース部１６は該当ファイルを主記憶１３に配置する。ページファイルにはアプリケーションが利用するメディアファイルのURLが列挙されており、ページファイルと同様にCPU１２はネットワークインタフェース部１６にこれらのファイルについてもダウンロード命令を発行し、ダウンロードされたファイルを主記憶１３やストレージ部１７に配置する。

実行に必要なファイルが用意された時点で、アプリ実行部プログラムは主記憶１３やストレージ部１７に配置されたページファイルをCPU１２が解釈できる命令に変換してCPU１２で実行する。ページファイルに含まれる配置データに従い、実行結果は情報操作装置１のディスプレイ１４に出力される。配置データには別のページファイルを表示および実行するためのボタン（リンク）が存在し、そのページファイルのURL情報が含まれる。ユーザ要求などによりそのボタンが選択されると、アプリ実行部プログラムは新たにページファイルのダウンロード要求を出し、そのページファイルで利用するメディアファイルも含めて、必要なファイルがそろった時点で新しいページファイルの表示および実行を開始する。

このページファイルなどに含まれるJavaScript（登録商標）と呼ばれるスクリプト言語を介して、HTTPやWebSocketプロトコルと呼ばれるプロトコルでHTTPサーバもしくはWebSocketサーバと通信することができる。すなわち、Webアプリ配布サーバ５側でHTTPやWebSocketを介した操作機能を提供する場合には、JavaScriptプログラムを用いて遠隔操作を行うことができる。Webアプリによりアプリケーション開発者は遠隔操作アプリケーションを簡単に作成できるが、このとき何もWebアプリ配布サーバ５側でアクセス制御を行わなければ、不正なWebアプリから遠隔操作が行われてしまうという危険性もある。このため、Webアプリを識別する情報として、WebSocketヘッダやHTTPヘッダに含まれるURL情報（Origin情報）がある。このURL情報を用いて情報出力装置３側でアクセス制御を行うことで、特定のサーバ上にあるWebアプリにのみ遠隔操作を許可することが出来るようになる。

しかしながら、HTTPやWebSocketプロトコルは公開情報であるため、HTTPやWebSocketプロトコルのURL情報を偽装するWebアプリの実行環境（以下、プラットホーム）が出現した場合には対処することが出来ない。このため、何らかの情報を用いてWebアプリが正しいプラットホーム上で動作していることをHTTPサーバやWebSocketサーバに伝える必要がある。正しいプラットホームであれば、そのプラットホームが付与したURL情報は信用できるためである。この情報として例えば、Webアプリ側で共通鍵を用いて機器操作命令を暗号化して送るといった解決策が考えられるが、Webアプリのページファイルはプレーンテキストで記述されており、機密情報を格納することはできないため、共通鍵の格納方法が問題になる。

また、Webアプリの難読化処理を行うことにより共通鍵を取得できにくくする手法もあるが、最終的にはブラウザが解釈可能な形式に変換されるため、比較的容易に共通鍵を取得できてしまい、セキュリティ強度に問題がある。

別の手法として、プラットホーム側で機器操作命令を暗号化することも考えられるが、プラットホームの実体であるブラウザに機器操作命令の暗号化機能を加えると、既存ブラウザへの変更が大規模になってしまい、得策でない。

HTTPやWebSocketプロトコルを用いて情報出力装置３の遠隔操作を行う際、操作を要求しているWebアプリの出所情報（URL情報）を用いてアクセス制御を行うことも考えられるが、HTTPやWebSocketプロトコルのヘッダに含まれるURL情報は信頼できない場合がある。なぜなら、HTTPやWebSocketプロトコルは仕様が公開されたプロトコルであり、詐称したURL情報を送るプラットホーム（偽ブラウザ）を開発することは比較的容易なためである。正しくアクセス制御を行うためには、操作を要求しているWebアプリが正しいプラットホーム上で動作し、URL情報が信頼できることを情報出力装置３に対して保証する必要がある。

以上の観点から、図１の情報処理システム４は、情報操作装置１が実行するWebアプリのURL情報が信頼できることを情報出力装置３に対して保証できるようにしている。

図２は第１の実施形態における情報操作装置１の内部構成を示すブロック図である。図２の情報操作装置１は、Webアプリを実行するWebアプリ実行部２１と、PFアプリを実行するPFアプリ実行部２２と、このPFアプリ実行部２２の内部に設けられるアプリ認証処理部２３と、情報出力装置３に機器操作命令と認証トークン（プラットホーム認証子）を送信する制御を行うIPコネクション管理部２４と、ユーザ入力を受け付ける入力受信部２５と、Webアプリ配布サーバ５からWebアプリを取得するHTTP処理部２６と、Webアプリの出所情報を認証トークンに付与するアプリ出所付与部２７と、情報出力装置３を検索する処理を行う機器検索処理部２８と、ウェブアプリケーションを取得するための第１のコネクションの確立処理を行い、ウェブアプリケーションを受信する第１コネクション部３３と、情報出力装置３との第２のコネクションを確立して認証要求を送信するとともに認証要求子を受信する第２コネクション部３４と、情報処理装置３との第３のコネクションを確立して機器操作命令と出所情報が付与されたプラットホーム認証子を送信する第３コネクション部３５と、機器検索を行うための第４のコネクションを確立して機器検索命令の送信を行うとともに検索結果を受信する第４コネクション部３６とを有する。

アプリ認証処理部２３は、Webアプリが正しいプラットホーム上で動作していることを保証する認証子（認証トークン）を生成する。

Webアプリ実行部２１は、ブラウザ上で動作するWebアプリを実行するための実行環境であるブラウザ機能を有する。PFアプリ実行部２２が実行するPFアプリは、直接計算機が実行できる命令形式で構成されるネイティブアプリケーションである。一方、Webアプリは、一般にプレーンテキスト形式で記述されたHTMLやJavaScriptファイル、これらから利用される各種メディアファイルなどである。

Webアプリ実行部２１が実行するWebアプリとPFアプリ実行部２２が実行するPFアプリは別々に開発できるが、Webアプリ実行部２１は一般に仕組みが複雑で新たな機能追加は困難である。何らかの特有の機能を実現したい場合には、アプリ認証処理部２３で目的機能を実現することができれば、ブラウザ内部を変更するよりも開発コストを下げて開発を行うことができる。また、Webアプリの記述言語であるHTMLやJavaScriptには秘密情報を含ませることは困難だが、PFアプリはネイティブアプリケーションであるため、秘密情報の保護強度を高くできる。

一方、PFアプリは、ブラウザの内部データ（例えばコネクションのデータや通信するデータ）を操作することが原則できず、ブラウザにより外部操作用インタフェースが公開されていない場合のみ、ブラウザの内部データを操作できるため、自由度は低くなる。

Webアプリ実行部２１は、HTMLやJavaScriptで記述されたWebアプリおよびWebアプリが参照する動画像や音声などのメディアファイルを取得し、実行および表示を行う機能を有する。Webアプリ実行部２１は、ユーザ入力を受け付ける入力受信部２５や後述する認証要求部からのアプリ実行要求を契機として、Webアプリの取得をHTTP処理部２６に要求し、取得したWebアプリの実行を開始する。

加えて、Webアプリ実行部２１は、WebアプリのJavaScript等で記述されたプログラムに遠隔機器操作命令が含まれる場合には、アプリ認証処理部２３に対して正規プラットホーム上でアプリが実行されていることを保証する認証子（認証トークン）の取得を依頼する機能を有する。アプリ認証処理部２３は、取得した認証トークンを、情報出力装置３の位置を識別するための情報（例えばFully Qualified Domain Name（FQDN）やIPアドレス）とともにアプリ出所付与部２７に渡す。アプリ出所付与部２７は、認証トークンにアプリの出所の位置識別子（例えばURL情報やOrigin情報）を付与する。ここで、Origin情報とはURLのドメイン部分であり、例えばhttp://www.toshiba.com/application_1/から取得したアプリケーションであればOriginはwww.toshiba.comとなる。

アプリ出所付与部２７は、アプリの出所の位置識別子を付与した認証トークンを情報出力装置３とのコネクションを管理する第３コネクション部３５を用いて情報出力装置３に送信するよう、IPコネクション管理部２４に指示する。IPコネクション管理部２４は、第３コネクション部３５に認証トークンを送るための第３のコネクション確立を指示して第３のコネクションを確立させて、その後に、第３コネクション部３５は認証トークンを情報出力装置３に送る。これにより、情報出力装置３は認証トークンが送られてきた第３のコネクションが正規のプラットホームにより確立されたコネクションであることを判別できる。また、情報出力装置３は、アプリの出所についても正規プラットホームにより付与されたものであることを判別できる。情報出力装置３側にいったん認証トークンが送信されると、再度別のコネクションで同一の認証トークンが送信されると、認証無効とされる（ワンタイムパスワードとする）。これにより、情報セキュリティを向上できる。

Webアプリ実行部２１はさらに機器操作命令を生成する機能を有し、IPコネクション管理部２４に対して第３コネクション部３５を利用して送信することを依頼する機能を有する。このため、IPコネクション管理部２４は第３コネクション部３５を利用して機器操作命令を情報出力装置３に対して送る機能を有する。情報出力装置３は既に第３コネクション部３５により認証トークンが送られているため、第３のコネクションが正規プラットホームにより確立されたコネクションであることが判別できているため、同じコネクションにより送られた機器操作命令についても正規プラットホーム上で動作するアプリケーションから送られていると判断でき、アプリケーションの出所についても正しく判別することが出来る。

アプリ認証処理部２３は、Webアプリ実行部２１からの認証トークン生成要求に対して、認証トークンを生成してWebアプリ実行部２１に渡す機能を有する。情報出力装置３が操作元のプラットホームが正しいことを検証するためには、情報出力装置３とアプリ認証処理部２３が認証を行う必要がある。このため、アプリ認証処理部２３は情報出力装置３と第２のコネクションが確立されていない場合にはIPコネクション管理部２４を通じて第２コネクション部３４に対して第２のコネクションの確立要求を出してコネクションを確立し、認証を要求する機能を有する。認証方式としてはパスワード認証、チャレンジ・アンド・レスポンスなど一般によく知られた方式を用いればよい。例えば認証方式としてチャレンジ・アンド・レスポンスを利用する場合には、アプリ認証処理部２３はIPコネクション管理部２４を通じて第２コネクション部３４を指定して第２のコネクションにより認証要求を送り、情報出力装置３から認証要求子であるチャレンジを受け取り、レスポンスを生成して認証子（認証トークン）としてWebアプリ実行部２１に渡す機能を有する。この後、Webアプリ実行部２１が第３コネクション部３５を指定してIPコネクション管理部２４から当該レスポンスを送れば、認証完了となる。また、通常のパスワード認証を用いる場合には、アプリ認証処理部２３が情報出力装置３に対して第２コネクション部３４を指定してIPコネクション管理部２４からパスワードを送信し、認証結果として情報出力装置３から受け取ったランダムな文字列をWebアプリ実行部２１に渡し、Webアプリ実行部２１が第３コネクション部３５を指定してIPコネクション管理部２４により当該文字列を送り、情報出力装置３が送った文字列と受け取った文字列が一致すれば第３のコネクションが正当なものであることが証明できる。

このように、第２のコネクションと第３のコネクションを分離することにより、情報出力装置３にWebアプリケーションに対して秘匿すべき情報、もしくは改ざんされては困る情報を送る際に、第２のコネクションを用いて秘匿すべきもしくは改ざんされて困る情報を送ることで、Webアプリケーションは第１のコネクションで送受信されるデータのみにアクセスできるため、情報を秘匿し、改ざんを防止することができる。

IPコネクション管理部２４は、上述した第１乃至第４コネクション部３３〜３６を含む複数のコネクション部を識別し、IPコネクション管理部２４の呼出し元から指定されたコネクション部を利用してデータを送信する。

第１コネクション部３３はIPコネクション管理部２４から呼び出され、IPコネクション管理部２４から指定されたWebアプリ配布サーバの位置情報とアプリケーションの位置情報を受け取り、Webアプリ配布サーバ５とのコネクションである第１のコネクションを確立したのち、Webアプリケーションを取得してIPコネクション管理部２４に返す機能を有する。

第２コネクション部３４はIPコネクション管理部２４から呼び出され、IPコネクション管理部２４から指定された情報出力装置３の位置情報を受け取り、第２のコネクションが確立されていない場合には確立を行い、情報出力装置３に認証要求を送信し、さらに情報出力装置３から認証要求子を受信してIPコネクション管理部２４に返却する機能を有する。

第３コネクション部３５はIPコネクション管理部２４から呼び出され、IPコネクション管理部２４から指定された情報出力装置３の位置情報を受け取り、第３のコネクションが確立されていない場合には確立を行い、IPコネクション管理部２４から渡された認証トークンや機器操作命令を送信する機能を有する。

第４コネクション部３６はIPコネクション管理部２４から呼び出され、IPコネクション管理部２４から受け取った機器検索命令を第４のコネクションを確立して送信し、受信した機器検索結果をIPコネクション管理部２４に返す機能を有する。

図３は図２の情報操作装置１内のWebアプリ実行部２１とアプリ認証処理部２３の内部構成を示すブロック図である。図３では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。以下、図３を用いて情報処理装置の詳細構成を説明する。

Webアプリ実行部２１は、Webアプリを表示および実行する機能を有するページ実行部５１（いわゆるウェブブラウザ）と、Webアプリから自分自身が正規プラットホーム上で動作していることを証明する認証子（認証トークン）を要求する機能を有する認証要求部５２と、遠隔機器操作命令を生成する機能を有する操作命令生成部５３と、機器操作命令を送信する機能を有する操作命令送信部５４と、認証トークンを送信する機能を有する認証トークン送信部５５とを有する。

ウェブブラウザからなるページ実行部５１以外の認証要求部５２、操作命令生成部５３、操作命令送信部５４および認証トークン送信部５５は、Webアプリ内のソフトウエアモジュールである。

アプリ認証処理部２３は、正しいプラットホームであることを証明するための認証トークンを生成する機能を有する認証トークン生成部６１と、アプリケーションが最初に表示するページのURLを管理する機能を有する開始アプリURL管理部６２と、認証トークンを生成するための鍵を管理する機能を有する鍵管理部６３と、HTTPサーバやWebSocketサーバに対して認証要求を行う機能を有する認証処理部６４とを有する。

アプリ認証処理部２３とWebアプリ実行部２１を分離することにより、Webアプリ実行部２１側に秘密の情報を格納することなく、安全にプラットホームの正当性を保証するための認証トークンを生成できるようになる。

Webアプリ実行部２１内のページ実行部５１は、入力受信部２５や開始アプリURL管理部６２からWebアプリの開始要求と開始位置情報（開始URL情報）を受け取り、Webアプリの実行を行う機能を有する。ページ実行部５１は、開始要求を受け取った場合には、HTTP処理部２６に対して開始URL情報を渡し、当該Webアプリの取得を行う。さらに習得したWebアプリに記述された処理内容を元にWebアプリの実行を行う機能を有する。さらに認証要求がWebアプリに含まれる場合に、情報出力装置３の位置情報（例えばIPアドレス）を指定して認証要求部５２を呼び出して認証トークンを取得した後、認証トークン送信部５５に認証要求部５２から取得した認証トークンを渡して呼び出す機能を有する。また、操作要求がWebアプリに含まれる場合に、機器操作命令の識別子を指定して操作命令生成部５３を呼び出して機器操作命令を生成し、操作命令送信部５４に機器操作命令を指定して呼び出す機能を有する。また、ページ実行部５１は実行中のアプリの出所の位置情報をアプリ出所付与部２７からの要求に従って渡す機能を有する。

認証要求部５２は、ページ実行部５１から情報出力装置３の位置情報を受け取り、アプリ認証処理部２３の認証トークン生成部６１を呼び出す機能を有する。また、認証トークン生成部６１から認証子（認証トークン）を受け取り、ページ実行部５１に渡す機能を有する。後述するように、認証子を多重に暗号化する場合にはユーザにパスワードを入力させ、そのパスワードを認証トークン生成部６１に渡してもよい。

認証トークン送信部５５は、ページ実行部５１から情報出力装置３の位置情報と認証トークンを受け取り、情報出力装置３の位置情報と認証トークンをアプリ出所付与部２７に渡して呼び出す機能を有する。また、認証トークン送信部５５はアプリ出所付与部２７からコネクション部の識別子（第３コネクション部３５の識別子）を受け取って、主記憶１３等に保存する機能を有する。

操作命令生成部５３は、ページ実行部５１から機器操作命令の種別を受け取って、特定のフォーマットで機器操作命令を生成し、ページ実行部５１に渡す機能を有する。このフォーマットは情報出力装置３と操作命令生成部５３の間で予め取り決めておけばフォーマットの詳細形式は問わない。

操作命令送信部５４はページ実行部５１から機器操作命令を受け取って、認証トークン送信部５５が主記憶１３等に保存したコネクション部の識別子を取得し、機器操作命令を送信メッセージ、送信先を第３コネクション部３５としてIPコネクション管理部２４に渡して呼び出す機能を有する。このとき、当該コネクションが切断されない限り、複数回の機器操作命令を認証トークンを再送することなく送信することができる。

アプリ出所付与部２７は、認証トークン送信部５５から認証トークンと情報出力装置３の位置情報を受け取って、認証トークンにアプリの出所の位置情報（URL情報）をページ実行部５１から取得して付与する。また、認証トークンにアプリ出所情報を付与したものを送信メッセージ、送信先を情報出力装置３の位置情報としてIPコネクション管理部２４に渡して呼び出す機能を有する。アプリ出所付与部２７により、情報出力装置３はどのアプリケーションが機器操作命令を発行したかを把握できる。

認証トークン生成部６１は、Webアプリ実行部２１の認証要求部５２からの認証要求を情報出力装置３の位置情報とともに受け取って、認証用コネクションである第２のコネクションが確立されていない場合にはIPコネクション管理部２４に対して認証用コネクションの確立を依頼する機能を有する。すなわち、認証要求命令を送信メッセージ、情報出力装置３の位置情報を送信先として渡し、第２コネクション部３４を呼び出して第２のコネクションの確立要求を行う機能を有する。第２のコネクションが既に確立されている場合には認証要求メッセージのみを送る。また、IPコネクション管理部２４からコネクション確立結果（コネクション確立を行った場合のみ）と認証先からのメッセージを受け取り、これらをアプリ認証処理部２３に渡して認証の実行を要求し、その結果を認証要求部５２に渡す。例えば、チャレンジ・アンド・レスポンスによる認証の場合には、IPコネクション管理部２４から認証要求命令の返答であるチャレンジを受け取ってアプリ認証処理部２３に渡す機能と、アプリ認証処理部２３からレスポンスを受け取って認証要求部５２に認証トークンとして返す機能とを有する。認証要求部５２からパスワードを受け取った場合には、アプリ認証処理部２３に認証の実行を要求する場合に、受け取ったパスワードもアプリ認証処理部２３に渡す。

アプリ認証処理部２３は、認証トークン生成部６１から認証要求を認証先から受け取ったメッセージと共に受け取って、鍵管理部６３に対して鍵取得命令を出し、受け取った鍵と認証先から受け取ったメッセージから認証トークンを生成する機能を有する。例えばチャレンジ・アンド・レスポンスでは、認証先から受け取ったメッセージ（チャレンジ）と鍵により、HMAC-SHA1、HMAC-MD5などの方式を用いてレスポンスを生成する。このレスポンスを認証トークンとして、認証トークン生成部６１に対して渡す機能を有する。このレスポンスを生成する前に、チャレンジを別の鍵でさらに暗号化してからレスポンスを生成してもよい。すなわち、レスポンスを多重に暗号化してもよい。この鍵としてはユーザが入力したパスワードを認証要求部５２から受け取って利用する方法等がある。暗号化の方法としては、AES等の共通鍵暗号やXOR演算など、一般に知られた方法を使えばよい。また同様にレスポンスを生成するための鍵を前記ユーザが入力したパスワードで暗号化してからその暗号化した鍵でレスポンスを生成してもよいし、生成したレスポンスをさらに前記ユーザが入力したパスワードで暗号化してもよい。

鍵管理部６３は、アプリ認証処理部２３からの鍵取得要求に対して鍵を渡す機能を有する。この鍵については、鍵管理部６３以外が読み取り不可能、もしくは読み取り困難な場所に格納し、その場所から取得する機能を有する。

開始アプリURL管理部６２は、アプリケーションの起動時に開始URL情報を二次記憶などから読み込んでページ実行部５１に渡してWebアプリの起動を要求する機能を有する。

IPコネクション管理部２４は、WebSocketプロトコルやHTTPなどの通信プロトコルを用いて、サーバとのコネクションの確立とデータの送受信を行う機能を有する。送信先サーバの指定としては、位置識別子（FQDN情報やIPアドレス情報）もしくは既に接続されたコネクション識別子情報を受け取り、位置識別子が指定された場合にはまず位置識別子情報を元に対応するサーバとのコネクションを確立する。その後、位置識別子が指定された場合には接続したコネクションを、既に接続されたコネクション識別子情報を受け取った場合には指定されたコネクションを用いて、呼出し元から指定された送信メッセージを送る機能を有する。また、サーバからの返答を受信し、呼出し元にコネクション情報と共に返す機能を有する。IPコネクション管理部２４は、第３コネクション部３５を介して認証トークンと機器操作命令を、第２コネクション部３４を介して認証要求を送ることができる。また、アプリケーションを取得する第１コネクション部３３を管理する機能も有する。このために複数コネクション部を同時に管理でき、呼出し元やコネクション識別子によって利用するコネクション部を分別する機能を有することを特徴とする。

また、IPコネクション管理部２４は、コネクション接続断や接続失敗が発生した場合に、接続断や接続失敗が発生したコネクション部を判別後に、そのコネクション部の確立要求元ブロックを判別してエラーを返す機能を備えていてもよい。加えて、情報操作装置１に後述の機器検索処理部２８を備える場合には、IPコネクション管理部２４は機器検索用コネクションである第４のコネクションを管理する第４コネクション部３６を別途管理する機能も有する。

機器検索処理部２８は、情報出力装置３の検索命令を受け取って機器検索命令を生成し、IPコネクション管理部２４とIPコネクション管理部２４から呼び出される第４コネクション部３６を用いて情報出力装置３を検索し、見つかった情報出力装置３の位置識別子のリストを返す機能を有する。この機器発見のプロトコルとしては、UPnP、NetBIOSなど一般に知られたプロトコルを用いればよい。Webアプリ実行部２１が情報出力装置３の位置識別子が予め分かっている場合など、必ずしも機器検索処理部２８は必須ではない。機器検索処理部２８により、予めネットワーク２内にどの被操作機器が存在するかといった情報を操作機器側に設定する必要がなくなる。機器検索処理部２８が存在しない場合には、第４コネクション部３６は必須ではない。

アプリ認証処理部２３は、機器検索処理部２８により取得した情報出力装置３の位置識別子を用いて、当該情報出力装置３との間で第２コネクション部３４を介して認証要求および認証トークンの送受を行う。

入力受信部２５は、ユーザ入力を受け取り、その入力に応じてページ実行部５１に対して入力内容を渡す機能を有する。例えば、ページに含まれるリンクのマウスやキーボードなどの外部入力装置による選択時にはページ実行部５１に選択情報を伝え、ページ実行部５１は受け取った選択情報に基づいてリンク先のページ取得、実行を行う。

HTTP処理部２６はサーバ上のデータ取得要求とともに取得データの位置識別子（URL情報）を受け取り、IPコネクション管理部２４および第１コネクション部３３を介してURL情報に対応するサーバに接続し、データ取得を行う機能を有する。受け取ったデータはデータ取得要求元に渡す機能を有する。

図４は第１の実施形態における情報出力装置３の内部構成を示すブロック図である。図４の情報出力装置３は、IPコネクション管理部７０、メッセージ分析部７１、認証用チャレンジ生成部７２、認証トークン検査部７３、機器操作命令処理部７４、アプリ出所検査部７５、機器検索応答部７６、第１〜第４コネクション部７８、３４〜３６を有する。本明細書では、情報操作装置１内の第２〜第４コネクション部３４〜３６と、情報操作装置１内の第２〜第４コネクション部３４〜３６に同一の符号を付している。すなわち、同一の符号の付されたコネクション部同士で、接続確立処理を行う。

IPコネクション管理部７０は、WebSocketプロトコルやHTTPなどの通信プロトコルを用いて、情報操作装置１とのコネクションの確立、データの送受信を行う機能を有する。IPコネクション管理部７０は、第２コネクション部３４と第３コネクション部３５を別々に管理し、第３コネクション部３５にて認証トークンや出所情報、機器操作命令を受信する機能と、第２コネクション部３４にて認証要求を受信して認証要求子である認証用チャレンジを送信する機能とを有する。このために、IPコネクション管理部７０は、複数コネクション部を同時に管理でき、呼出し元やコネクション識別子によって利用するコネクション部を分別する機能を有することを特徴とする。加えて、情報出力装置３が後述の機器検索応答部を備える場合には、IPコネクション管理部７０は機器検索用コネクションの確立や検索命令の受信と検索命令への応答送信を行う第４コネクション部３６を別途管理する機能も有する。また、IPコネクション管理部７０は許可出所リストを取得する第１コネクション部７８を別途管理する機能を有してもよい。

メッセージ分析部７１は、第３コネクション部３５を介して受信した命令を、機器操作命令、認証トークンおよび出所情報に分割し、認証トークンは認証トークン検査部７３に渡し、出所情報はアプリ出所検査部７５に渡す機能を有する。機器操作命令については、アプリ出所検査部７５や認証トークン検査部７３からの検査結果を受け取り、出所情報および認証トークンが適正と判断された場合にのみ、機器操作命令処理部７４に渡す機能を有する。

認証用チャレンジ生成部７２は、IPコネクション管理部７０から第２コネクション部３４を介して認証要求が渡された場合に、認証用チャレンジを生成して第２コネクション部３４を介して要求元に返す機能を有する。このチャレンジの生成方法はランダムな文字列の生成などで良い。また、認証用チャレンジに対するレスポンスを情報出力装置３に格納される鍵情報（共通鍵）を用いて生成して、検証用認証トークン情報として保存する機能を有する。

認証トークン検査部７３は、第２コネクション部３４を介して渡された認証トークンを検査する機能を有する。認証用チャレンジ生成部７２が保存した検証用認証トークン情報の中に渡された認証トークンが存在するかどうかを確認し、存在する場合には認証トークンが適正という結果を返し、存在しない場合には認証トークンが不正という結果を返す。認証トークンが適正な場合には、保存された検証用認証トークン情報を削除する機能を有する。これにより、一回の認証でのみ有効なパスワード（ワンタイムパスワード）を生成できる。

機器操作命令処理部７４は、情報操作装置１から受信した機器操作命令を処理し、不図示のチューナー部を制御したり、不図示の画面出力部に表示する映像等を切り替える指示を送ったりする機能を有する。

アプリ出所検査部７５は、第３のコネクションの確立時のヘッダ情報を分析し、コネクション確立要求を行ったアプリケーションの出所を判定し、許可出所リストにその出所が含まれるか否かを判定して、含まれる場合には出所が適正という結果を返し、含まれない場合に不正という結果を返す機能を有する。ここで、許可出所リストとは、認証トークンの発行を行うことが可能なWebアプリの取得先をリストアップしたものであり、Webアプリごとに設けられる。許可出所リストは、例えばWebアプリ配布サーバ５が管理する。

機器検索応答部７６は、後述する情報操作装置１からの装置検索要求に応答して、自装置の名前やIPアドレスを返信する処理を行う。装置検索のプロトコルとしてUPnP規格で定められた方式や、NetBIOSによる名前検索方式を用いてもよい。なお、この機器検索応答部７６は必須の構成ではない。

図５は第１の実施形態におけるWebアプリ配布サーバ５の内部構成を示すブロック図である。図５の情報出力装置３は、HTTPサーバ処理部４３と、コンテンツ・メディアファイル取得部４４とを有する。HTTPサーバ処理部４３の内部には図１に示したネットワークインタフェース部４１が設けられ、コンテンツ・メディアファイル取得部４４の内部には図１に示したストレージ部４２が設けられている。

HTTPサーバ処理部４３は、情報操作装置１から渡されたURL情報をコンテンツ・メディアファイル取得部４４に渡してファイル取得を要求し、受け取ったファイルを情報操作装置１に渡す機能を有する。

コンテンツ・メディアファイル取得部４４はHTTPサーバ処理部４３から渡されたURL情報をWebアプリ配布サーバ５が備える不図示のストレージ内のファイル位置に変換し、ストレージ部からファイルを読み込んで、HTTPサーバ処理部４３に渡す機能を有する。

図６は情報操作装置１内のWebアプリ実行部２１とアプリ認証処理部２３の起動時の処理手順の一例を示すフローチャートである。起動時にはアプリ（装置）毎に設定された最初に表示するページをWebアプリ配布サーバ５から取得して実行する。以下はその詳細である。

アプリ認証処理部２３内の開始アプリURL管理部６２は、ストレージ等の開始アプリURL管理部６２の管理する領域からアプリケーション起動時に最初に表示するページのURL情報をロードし、ページ実行部５１に対してURL情報を渡してページ表示を要求する（ステップＳ１）。

ページ実行部５１はURL情報を受信し、HTTP処理部２６に対してURL情報が指すページデータの取得を要求する（ステップＳ２）。

HTTP処理部２６は、URLが指すサーバに接続し、URL情報に基づいてページ取得命令を出して、ページのデータ取得後、ページ実行部５１にデータを返す（ステップＳ３）。ページ実行部５１は取得したデータを元にWebアプリの実行を開始する（ステップＳ４）。

情報操作装置１毎に管理するURL情報を変えることで、サーバ上から取得するページデータが変わるため、処理内容を変更することができる。例えばチャンネル変更アプリ（装置）と、録画視聴アプリ（装置）を別のアプリケーションとして実現することが可能となる。

Webアプリの実行中に認証要求命令が現れた場合には、プラットホームの正当性を示す認証トークンの認証用コネクション（第２のコネクション）の確立と、情報出力装置３との機器操作用コネクション（第３のコネクション）の確立とを行う。

図７はチャレンジ・アンド・レスポンスによる認証を行う際の認証要求命令検知時の処理手順の一例を示すフローチャートである。

ページ実行部５１はWebアプリの実行中に認証要求命令を検知すると（ステップＳ１１）、認証要求部５２に対して情報出力装置３の位置情報を渡して認証要求を行う。この際にユーザにパスワード入力を要求して受け取ったパスワードを認証要求部５２に渡してもよい。次に認証要求部５２は認証トークン生成部６１に対して情報出力装置３の位置情報とパスワードを受け取った場合にはパスワードを渡して認証トークンの生成を要求する（ステップＳ１２）。

認証トークン生成部６１は、第２コネクション部３４の情報を取得し（ステップＳ１３）、第２のコネクションが既に確立されているか確認する（ステップＳ１４）。まだ確立されていない場合には情報出力装置３の位置情報からIPコネクション管理部２４に対して情報出力装置３とのコネクション（認証用コネクション、第２のコネクション）の確立を要求する（ステップＳ１５）。IPコネクション管理部２４は第２コネクション部３４を用いて情報出力装置３との第２のコネクションを確立させる。第２のコネクションの確立後、認証トークン生成部６１は第２コネクション部３４の識別子情報を主記憶１３等に保存する（ステップＳ１６）。

ステップＳ１６の処理が終了した場合か、あるいは既に第２のコネクションが確立されていた場合は、情報出力装置３にIPコネクション管理部２４に対して第２コネクション部３４を通じて認証要求を送信する（ステップＳ１７）。

IPコネクション管理部２４は、第２コネクション部３４を通じて情報出力装置３からのチャレンジを受信して（ステップＳ１８）、第２コネクション部３４は認証トークン生成部６１にチャレンジを返す。この際に第２のコネクションの確立を破棄してもよい。次に認証トークン生成部６１はアプリ認証処理部２３に対して受信したチャレンジを渡し、レスポンスの依頼を生成する（ステップＳ１９）。

アプリ認証処理部２３は、情報出力装置３からのチャレンジを受けると、レスポンスを生成するための鍵の取得を鍵管理部６３に対して要求する。鍵管理部６３はアプリ認証処理部２３からの要求に従い、ストレージ等から鍵を取得して、アプリ認証処理部２３に対して鍵を返す（ステップＳ２０）。その後、アプリ認証処理部２３は、取得した鍵とチャレンジからレスポンスを生成して認証トークン生成部６１に対して返す（ステップＳ２１）。レスポンスを生成するためのアルゴリズムとしてはHMAC-SHA1、HMAC-MD5など、一般に知られた方法を使えばよい。この際に、チャレンジやレスポンス、チャレンジ生成に用いる鍵をさらにページ実行部５１から受け取ったパスワードで暗号化してもよい。

認証トークン生成部６１は、認証トークン送信部５５に対して、認証要求部５２に対する認証トークンを返す。このとき、認証トークンを送信メッセージとし、情報出力装置３の位置情報を接続先情報として、認証トークン送信部５５に認証トークンの送信を依頼する（ステップＳ２２）。

認証トークン送信部５５は、出所情報付与部に対してコネクション確立要求を認証トークンと共に渡し、出所情報付与部はアプリの出所の位置情報（URL情報）をページ実行部５１から取得して送信データに付与し（ステップＳ２３）、送信データと接続先情報をIPコネクション管理部２４に渡す。

IPコネクション管理部２４は、受け取った接続先情報を元に情報出力装置３との第の３コネクション（操作用コネクション）を第３コネクション部３５を介して確立させる（ステップＳ２４）。

その後、IPコネクション管理部２４は、第３コネクション部３５を介して情報出力装置３へ認証トークンを送信し（ステップＳ２５）、第３コネクション部３５の識別子情報を認証トークン送信部５５に返す。最後に、認証トークン送信部５５は受け取った第３コネクション部３５の識別子情報を主記憶１３などに保存する（ステップＳ２６）。この際に第３コネクション部３５は第３のコネクションを切断しないことにより、第３コネクション部３５を用いて何度でも機器操作命令を送信できる。

第３のコネクションは、WebSocketプロトコルではページ実行部５１によるページ移動、すなわち別ページの実行開始時や、Webアプリ自身による明示的なコネクション切断によりコネクションが切断される。その際には図７に示される認証処理が再度行われる。HTTPでは一般に通信の度にコネクションが切断されるため、認証トークンと機器操作命令を同時に送信する。

Webアプリの実行中に機器操作命令が現れた場合には、第３コネクション部３５を介して機器操作命令を送信する。

図８は情報操作装置１から情報出力装置３への機器操作命令の送信手順の一例を示すフローチャートである。ページ実行部５１はWebアプリの実行中に機器操作命令が現れると、操作命令生成部５３に対して操作要求内容を通知して、機器操作要求の生成依頼を行う（ステップＳ３１）。

操作命令生成部５３は第３コネクション部３５を介して第３のコネクションで送ることのできる形の機器操作命令を特定のフォーマットで生成し、ページ実行部５１に返す（ステップＳ３２）。ページ実行部５１は操作命令生成部５３から受け取った機器操作命令を操作命令送信部５４に対して渡し、機器操作命令の送信を依頼する。操作命令送信部５４は、主記憶１３等から第３のコネクション確立時に認証トークン送信部５５が保存した第３コネクション部３５の識別子情報を取得する（ステップＳ３３）。

識別子情報が取得出来ない場合には（ステップＳ３４）、操作命令送信部５４は第３のコネクションが確立されていないものと見なしてエラーをページ実行部５１に対して返す（ステップＳ３５）。識別子情報がある場合には操作命令送信部５４はIPコネクション管理部２４に対して、ページ実行部５１から受け取った機器操作命令と主記憶１３等から取得した第３コネクション部３５の識別子情報を渡し、機器操作命令の送信を依頼する。IPコネクション管理部２４は第１コネクション部の識別子情報からコネクションを特定し、第３コネクション部３５に機器操作命令を渡して機器操作命令を送信する（ステップＳ３６）。ここでも、第３のコネクションについては切断しないことにより、第３コネクション部３５を用いて何度も機器操作命令を送信することが可能となる。

図９は認証要求受信時の情報出力装置３の処理手順の一例を示すフローチャートである。情報出力装置３のIPコネクション管理部７０は、第２コネクション部３４により第２のコネクションが確立されて認証要求を受信すると（ステップＳ４１）、認証用チャレンジ生成部７２に対して認証要求子（チャレンジ）の生成を要求する（ステップＳ４２）。認証用チャレンジ生成部７２はその要求に対して、例えばランダム文字列を生成してチャレンジとする。また、情報出力装置３の不図示のストレージなどの格納領域に保存されている認証用鍵を取得し（ステップＳ４３）、チャレンジに対応する認証子（レスポンス）を生成し、認証子リスト（レスポンスリスト）に登録する（ステップＳ４４）。この際に、パスワードでさらにチャレンジもしくはレスポンス、もしくはチャレンジを生成するための認証用鍵で暗号化してもよい。さらに、生成した認証要求子（チャレンジ）をIPコネクション管理部７０に返し、IPコネクション管理部７０は情報操作装置１に対して第２コネクション部３４を介して認証要求子を返す（ステップＳ４５）。

図１０は第３のコネクション確立要求時の情報出力装置３の処理手順の一例を示すフローチャートである。情報出力装置３のIPコネクション管理部７０は、第３コネクション部３５を通じて第３のコネクションの確立要求を受信した場合に（ステップＳ５１）、メッセージ分析部７１を呼び出す。メッセージ分析部７１はコネクション確立要求のメッセージに含まれる確立要求元のWebアプリの出所情報を取得し（ステップＳ５２）、アプリ出所検査部７５に渡す。

アプリ出所検査部７５は不図示の情報出力装置３のストレージ等の格納領域から許可出所リストを取得し、取得した出所情報が許可出所リストに含まれるかどうか判定する（ステップＳ５３）。含まれない場合には、エラーを発生させ（ステップＳ５４）、第３のコネクションを切断する。一方、含まれた場合には、メッセージ分析部７１は同じくコネクション確立要求のメッセージに含まれる認証トークン（認証子）情報を取得し（ステップＳ５５）、認証トークン検査部７３に渡す。

認証トークン検査部７３は認証用チャレンジ生成部７２から認証子リスト（レスポンスリスト）を取得し、受信した認証トークン情報がレスポンスリストに含まれるかどうか判定する（ステップＳ５６）。含まれた場合には、正しい認証子が送られてきたと判定し、第３のコネクション確立を完了する（ステップＳ５７）。一方、レスポンスリストに受信した認証トークン情報がない場合には、不正なコネクションが張られたものとしてコネクションを切断する（ステップＳ５４）。

図１１は第１の実施形態における認証トークンの生成と機器操作命令の送信を含む情報操作装置１と情報出力装置３の処理手順の一例を示すシーケンス図である。

情報操作装置１は初回の認証要求時にまず、情報出力装置３に対して第２コネクション部３４により第２のコネクションの確立を要求する（ステップＳ６１）。次に、情報操作装置１は情報出力装置３で生成した認証用チャレンジを受け取り（ステップＳ６２、Ｓ６３）、レスポンスを生成して認証トークンとする（ステップＳ６４）。

次に、第３コネクション部３５による第３のコネクションの確立要求に先立ち、情報操作装置１は送信メッセージにWebアプリの出所情報の付与を行い（ステップＳ６５）、情報出力装置３に対して第３のコネクションの確立要求と共に出所情報を送信する（ステップＳ６６）。

情報出力装置３は、第３のコネクションを介して渡された認証トークンの検証を行い（ステップＳ６７）、正しい場合には処理を続行する。また、情報操作装置１は情報出力装置３への機器操作命令送信を第３コネクション部３５を介して行う（ステップＳ６８）。ページ遷移などによって第３のコネクションが切断された場合には、情報操作装置１は第２コネクション部３４を介して再度認証要求を行う（ステップＳ６９）。その後に、情報操作装置１は第３のコネクションを切断する（ステップＳ７０）。

第２のコネクションが切断されていなければ、再度第２コネクション部３４により第２のコネクションの確立要求を行う必要はない。認証要求を行った（ステップＳ７１）後は、ステップＳ６２以降の処理を繰り返す。

このように、本実施形態によれば、プラットホームの正当性を保証する認証トークンを機器操作命令の送信用セッションの通信に付与することができる。すなわち、従来は出所情報が信頼できないため困難だったHTTPやWebSocketなどにおけるWebアプリの出所情報を用いた情報出力装置３の機器アクセス制御を情報出力装置３側で確実に行えるようになる。これにより、Webアプリによって可能な機器操作の内容を変えるといった柔軟な遠隔操作時のアクセス制御の実現が可能になる。

例えば、被操作機器の録画コンテンツの削除機能についてWebSocketプロトコルを介してwww.toshiba.comで配布するWebアプリに公開したとする。WebSocketに含まれるヘッダのチェックのみの場合、アプリケーションの実際の出所にかかわらず出所情報としてwww.toshiba.comを付加するような情報操作装置１にもコンテンツ削除を許してしまい、www.toshiba.com以外のサーバ、特に誰でもWebアプリが自由に置けるようなサーバに置かれた悪意あるWebアプリからコンテンツ削除が行われてしまう可能性がある。

本実施形態は、Webアプリ実行部２１とアプリ認証処理部２３が分離されていることに大きな特徴がある。一般にWebアプリの処理内容を記述するための言語であるJavaScriptに秘密情報を持たせることは困難であり（JavaScript等のWebアプリ実行部２１の一部に相当）、プラットホームの正当性を保証するための鍵などを格納するには不適当である。そこで本実施形態では、Webアプリ実行部２１とアプリ認証処理部２３を分離し、解析が困難なアプリ認証処理部２３側に秘密情報である鍵情報を持たせ、認証の一部や認証トークン生成処理を実行することで、同等の動作すなわち、本実施形態のエミュレートを行うプラットホームの作成を困難にしている。Webアプリ実行部２１とアプリ認証処理部２３が分離されている本実施形態では、認証要求部５２と認証トークン生成部６１が両モジュールを結びつける機能を有する。

認証トークン生成用の共通鍵を取得できないと、情報出力装置３との認証が通らないため、情報出力装置３は正しいプラットホームからの機器操作命令かどうかを正しく判別できる。

また、Webアプリの実行環境自体（ブラウザ）には手を加えられないことが多いが、本実施形態ではアプリ認証処理部２３とブラウザ部分（Webアプリ実行部２１の一部）が明確に分離されており、アプリ認証処理部２３をプラグインなどとして実装することができる利点もある。

さらに、アプリ認証処理部２３とWebアプリ実行部２１側ではモジュールが分離されることや、実装に使用する言語などが異なる可能性があり、同じコネクションを共有できないことも多いと考えられる。このため、本実施形態では、Webアプリ実行部２１が利用する操作用のコネクション（第３のコネクション）を管理する第３コネクション部３５とアプリ認証処理部２３が利用する認証用のコネクション（第２のコネクション）を管理する第２コネクション部３４を分離していることも大きな特徴である。

コネクションを分離した場合、同一の情報操作装置１との間で第２のコネクションと第３のコネクションとが確立されたことを情報出力装置３側で確認できる必要がある。すなわち、第３のコネクションがプロトコルを模倣する悪意あるアプリケーションから張られたものか、正規アプリケーションから張られたものかを区別する必要がある。これを解決するために、本実施形態では秘密情報を格納できないWebアプリ実行部２１から確立された第３のコネクションを管理する第３コネクション部３５では、第２コネクション部３４を介してアプリ認証処理部２３で生成した認証トークンをアプリ認証処理部２３から受け取って送ることにより正しいプラットホーム上から確立された操作コネクションであることを情報出力装置３に対して証明するための仕組みを持つ。本機能を実現するために第３コネクション部３５と第２コネクション部３４を独立して管理するためのIPコネクション管理部２４を備えることが本実施形態の特徴的な点である。

関連する技術としてモバイルエージェント向けのセキュリティに関する研究や特許、例えばモバイルエージェントが移動する先のプラットホームでモバイルエージェントの正しさの検証を行う研究や特許が存在する。特許文献１では移動元のプラットホームでモバイルエージェントに署名を付与し、移動先でモバイルエージェントが改ざんされていないことを検証することにより、改ざんされた不正なモバイルエージェントの動作を防止できる。しかしながら、本実施形態で前提とするシステムでは機器操作コードを含むアプリケーションに署名したとしても情報出力装置３が受信するのは機器操作命令のみであるため、アプリケーションの署名検証はできず、そのアプリケーションの正しさは保証できない。また、機器操作命令のみに署名することも考えられるが、機器操作プロトコルを模倣するプラットホーム上で署名された機器操作命令全体をコピーされて別のアプリケーションに流用される可能性がある。本実施形態によれば、機器操作命令をコピーされても、ネイティブコードで記述されるコード中に含まれて抜き出し困難な認証鍵（共通鍵）がコピーされない限り、認証トークンを生成できず、機器の不正な操作を行うプラットホームは作成できない。

このように、第１の実施形態では、情報操作装置１が実行したWebアプリに従って、情報出力装置３に対して第２コネクション部３４により第２のコネクションの確立と認証要求を行い、これを受けて情報出力装置３は、認証要求子（チャレンジ）を生成して、情報操作装置１に送信する。

この認証要求子を受信した情報操作装置１は、鍵管理部６３で管理する共通鍵を用いて認証要求子を暗号化し、認証トークンを生成する。この認証トークンは、認証要求子を送信した情報出力装置３に送信され、認証トークンを受信した情報出力装置３は、自身が所持する共通鍵で認証要求子を暗号化して、受信したものと一致するかどうかにより認証トークンが正規の情報操作装置１から送信されたものかどうかを検証できる。

また、情報操作装置１は、認証トークンを情報出力装置３に送信する前に、認証トークンと機器操作命令を送信するための第３のコネクションの確立要求を情報出力装置３に送信する。その際、第３のコネクションの確立要求のヘッダ情報として、Webアプリの出所情報を含める。第３のコネクションの確立要求を受信した情報出力装置３は、この確立要求に含まれるWebアプリの出所が、自身が有する許可出所リストに登録されているか否かを検証し、登録されている場合のみ、第３のコネクションの確立処理を行う。これにより、意図しないWebアプリから送信された機器操作命令で、情報出力装置３が勝手に操作されてしまうことを防止できる。

さらに、情報操作装置１は、Webアプリ配布サーバ５からWebアプリを取得するための第１のコネクションを管理する第１コネクション部３３と、認証子および認証要求子の送受を行うための第２のコネクションを管理する第２コネクション部３４と、認証トークンおよび機器操作命令を送信するための第３のコネクションを管理する第３コネクション部３５とを別個に設けて、これらコネクション部の管理をIPコネクション管理部２４で行うため、各コネクションで送受される各種情報を統一的に管理できる。

また、認証トークンの生成等に用いる共通鍵をPFアプリ実行部２２内のアプリ認証処理部２３に保持し、HTMLやJavaScript等の汎用言語で記述されるWebアプリを実行するWebアプリ実行部２１内では共通鍵を管理しないようにしたため、共通鍵を安全に管理することができる。

（第２の実施形態）
第１の実施形態では、アプリ認証処理部２３はページ実行部５１で実行しているWebアプリの出所について検査を行っていなかった。このため、例えば悪意あるWebアプリが動作し、認証要求を行った場合にも認証トークンを渡してしまうという欠点が存在した。このため、悪意あるWebアプリが認証トークンを外部に渡すような場合、第３コネクション部３５で送受信される情報を模倣する悪意あるプラットホームと連携して情報出力装置３の不正な操作が可能になってしまう。このため、第２の実施形態では、Webアプリの出所チェックを行うことで、例えば信頼できるWebアプリ配布サーバ５から取得したWebアプリにのみ認証トークンを渡すようにでき、認証トークンの不正利用を防ぐことが可能となる。

図１２は第２の実施形態における情報操作装置１の内部構成の一例を示すブロック図である。図３のアプリ認証処理部２３に、アプリ出所検査部６５と許可出所リスト検査部６６を追加した点で異なる。このうち、許可出所リスト検査部６６は必須の構成ではない。なお、図１２では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。

アプリ出所検査部６５は現在実行中のページの出所情報から、その出所に認証トークンを渡して良いかどうか判定する機能を有する。このためにアプリ出所検査部６５は、認証要求部５２から認証トークン生成部６１に対して認証トークンの生成要求があった際に、ページ実行部５１から現在実行中のページの出所情報を取得する。また、情報操作装置１内のストレージ部１７、主記憶１３などデータ格納領域からトークンを渡しても良い出所情報のリスト（以下、許可出所リスト）を取得し、そのリストの中に現在実行中のページの出所情報が含まれるかどうかを判定する。出所情報が含まれる場合には、認証トークンを渡して良いと判定して処理を続行し、出所情報が含まれない場合には認証トークンを渡してはいけないと判定してページ実行部５１に対してエラーを返す機能を有する。例えば、www.toshiba.com、www.toshiba.co.jpドメインが許可出所リストに含まれる場合には、実行中のWebアプリがwww.toshiba.comドメインから取得したWebアプリの場合には認証トークンを渡すが、www.toshiba.co.ukドメインから取得したWebアプリの場合には認証トークンを渡さない。また本情報操作装置１が許可出所リスト検査部６６を備える場合には、許可出所リストを渡して、許可出所リストの正当性検証を依頼する機能を有する。

また、許可出所リストが改ざんされると想定していない情報出力装置３に対して認証トークンを渡してしまう危険性がある。このため、第２の実施形態における情報操作装置１には許可出所リストの改ざん検証を行う許可出所リスト検査部６６を備えても良い。アプリ出所リストをリードオンリーメモリなど改ざんが困難な格納領域に保存できる場合には、許可出所リスト検査部６６は必須の構成ではない。許可出所リスト検査部６６は、許可出所リストに付与された署名を許可出所リスト検査部６６が持つ公開鍵を用いて検証して改ざんの検証を行い、改ざんが検出された場合にはエラーを返す機能を有する。署名検証の方法としては、RSA署名、DSA署名など一般に知られた方式を使えばよい。

図１３は許可出所リスト１０のデータ構造の一例を示す図である。許可出所リスト１０は許可出所リスト部１０ａと署名部１０ｂとに分かれ、許可出所リスト部１０ａには（1）許可する出所の数、（2）許可する出所のリスト（要素数は（1）で指定したもの）が含まれる。このとき許可する出所情報には、例えばＰＯＳＩＸ規格により定められる、文字列の集合を一つの文字列で表現する方法の一つである正規表現を使った情報を含んでも良い。一方、署名部１０ｂには、許可出所リスト部１０ａに対する改ざんを検証するための署名が含まれる。この署名は許可出所リスト検査部６６が持つ公開鍵に対する秘密鍵により署名されている。

図１４は認証要求命令検出時の処理手順の一例を示すフローチャートである。図１４のフローチャートは、図７と比較して、（1）〜（4）のアプリ出所検証処理が入る点が異なる。ここでは（1）〜（4）の処理のみを説明する。

認証トークン生成部６１は認証要求部５２から認証要求があった際に、アプリ出所検査部６５にアプリ出所検査を依頼する。アプリ出所検査部６５は、ページ実行部５１から現在実行中の認証要求があったWebアプリの出所を取得する（ステップＳ８１）。すなわち、ページ実行部５１は現在実行中のWebアプリの出所を取得し、要求に応じて出所データを返す機能を有する。

次に、アプリ出所検査部６５はストレージ等の記憶装置から許可出所リストを取得する（ステップＳ８２）。また、情報操作装置１が許可出所検査部を備える場合には、アプリ出所検査部６５は許可出所リスト検査部６６に対して許可出所リストを渡し、許可出所リストの改ざん検証を依頼する。許可出所リスト検査部６６は自身が管理する許可出所リスト検査部６６に付与された署名を検証するための公開鍵を取得する（ステップＳ８３）。許可リスト検査部はこの公開鍵を用いて許可出所リストの署名を検証する（ステップＳ８４）。検証の結果、改ざんが検出されなければ、アプリの出所が許可出所リストに含まれるか否かを判定する（ステップＳ８５、Ｓ８６）。

ステップＳ８４で改ざんが検出された場合、またはステップＳ８５で許可出所リストに含まれないと判定された場合は、ページ実行部５１にエラーを返し（ステップＳ８５、Ｓ８７）、許可出所リストに含まれる場合は、図７のステップＳ１３以降の処理を行う。

本実施形態により、許可出所リストの制作者が想定した以外のWebアプリ配布サーバ５上に置かれたWebアプリに対して認証トークンを生成することを防止でき、認証トークンを不正なWebアプリに対して生成するリスクを下げることができる。認証トークンの不正利用のリスク、すなわち不正なWebアプリによる遠隔操作を防ぐことが出来るようになる。

このように、第２の実施形態では、情報出力装置３に認証要求を行う際に、認証要求を行ったWebアプリの出所が許可出所リストに登録されているか否かを情報操作装置１の内部で検証するようにしたため、意図しないWebアプリからの認証要求を情報出力装置３に送信するおそれがなくなる。

（第３の実施形態）
第２の実施形態では許可出所リストの更新を行っていなかった。このため許可出所リストは固定で、遠隔操作を許可するWebアプリが置かれるWebアプリ配布サーバ５の追加や削除ができない。これに対して第３の実施形態では許可出所リストの更新を行い、Webアプリ配布サーバ５の追加や削除が可能となる。

図１５は第３の実施形態における情報操作装置１の内部構成の一例を示すブロック図である。図１５は図３のアプリ認証処理部２３内に許可出所リスト取得部６７を追加した点で異なる。なお、図１５では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。

許可出所リスト取得部６７は、HTTP処理部２６を利用してIPコネクション管理部２４とIPコネクション管理部２４から呼び出される第１コネクション部３３を介してWebアプリ配布サーバ５から許可出所リストを取得し、更新されていた場合には、許可出所リスト検査部６６に取得した許可出所リストを渡して検証依頼を出す機能を有する。例えば更新されているかどうかの判定は、情報操作装置１内に保存されている許可出所リストとの比較や、リストファイルの最終更新日時との比較を行えばよい。さらに許可出所リスト検査部６６の検証結果を取得し、改ざんが検出されなかった場合に情報操作装置１のストレージ内部に保存されている許可出所リストをWebアプリ配布サーバ５から取得した許可出所リストに置き換える機能を有する。

図１６は第３の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図である。図５のWebアプリ配布サーバ５に許可リスト取得部４５を追加した点で異なる。

許可リスト取得部４５は情報操作装置１もしくは情報出力装置３からの要求に従い、不図示のストレージから最新の許可出所リストを取得し、HTTPサーバ処理部４３を介して要求元に返す機能を有する。Webアプリ配布サーバ５が管理する許可出所リストを更新することにより、情報操作装置１や情報出力装置３は許可出所リストを最新の情報に保つことができる。

図１７は許可出所リスト更新の処理手順の一例を示すフローチャートである。許可リスト取得部４５は、情報操作装置１の起動時もしくは、一定期間ごとに定期的に呼び出され、最新の許可出所リストをHTTP処理部２６とHTTP処理部２６から呼び出されるIPコネクション管理部２４とIPコネクション管理部２４から呼び出される第１コネクション部３３を介してWebアプリ配布サーバ５から取得（ダウンロード）する（ステップＳ９１）。そして、情報操作装置１内に保存された許可出所リストとの比較を行う（ステップＳ９２）。更新がなかったと判定された場合は処理を終了し、更新があったと判定された場合には、署名検証用の公開鍵を情報操作装置１内から取得し（ステップＳ９３）、Webアプリ配布サーバ５から取得した許可出所リストの署名を検証する（ステップＳ９４）。改ざんがあった場合にはエラーを発生させ（ステップＳ９５、Ｓ９６）、改ざんが検出されなかった場合には情報操作装置１内に保存されていた許可出所リストをWebアプリ配布サーバ５から取得した許可出所リストで上書きする（ステップＳ９５、Ｓ９７）。

このように、第３の実施形態では、Webアプリ配布サーバ５で許可出所リストの更新を行うことから、情報操作装置１から定期的にWebアプリ配布サーバ５にアクセスして、許可出所リストの最新版を取得することで、情報操作装置１が保持する許可出所リストを常に最新のものに維持できる。

（第４の実施形態）
以下に説明する第４の実施形態では、アプリケーション毎に信頼できるサーバが発行する利用許可証に許可出所リストを付与し、そのリストを元に認証トークンを渡して良いか判断する機能を有する。Webアプリ単位で許可出所情報を変更することが可能になる。ここで、利用許可証とは、機器操作命令を送信するWebアプリが正規のWebアプリ配布サーバ５から配布されたものであることを証明する情報であり、利用許可証はWebアプリごとに発行される。すべてのWebアプリに対応して利用許可証が発行されるわけではなく、利用許可証を利用できるWebアプリは制限されている。

図１８は第４の実施形態における情報操作装置１の内部構成の一例を示すブロック図である。図１８は図３のアプリ認証処理部２３内に利用許可証分析部６８を追加し、かつ図３のWebアプリ実行部２１内に利用許可証管理部５６を追加した点で異なる。なお、図１８では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。

利用許可証管理部５６はIPコネクション管理部２４とIPコネクション管理部２４から呼び出される第１コネクション部３３を介して信頼できるサーバからWebアプリ毎にWebアプリ配布サーバ５から利用許可証を取得し、利用許可証分析部６８に渡す機能を有する。この際にはアプリケーションの識別情報を渡す。利用許可証には、機器操作の許可情報と共に、許可出所リスト情報、署名情報が含まれる。この署名は公開鍵暗号で署名される。公開鍵暗号方式としてはRSA暗号など、一般に知られた方法を用いればよい。

利用許可証分析部６８は利用許可証管理部５６から取得した利用許可証を分析し、許可出所リストを取り出す機能を有する。

図１９は第４の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図である。図５のWebアプリ配布サーバ５に利用許可証生成部４６を追加した点で異なる。

利用許可証生成部４６は情報操作装置１からの利用許可証の取得要求に従って、Webアプリ毎の利用許可証を生成して返す機能を有する。利用許可証生成部４６はWebアプリの識別情報を受け取り、Webアプリに対応する許可出所リスト情報や機器操作の許可情報を不図示のストレージから取得して、署名してHTTPサーバ処理部４３を介して要求元に返す機能を有する。利用許可証生成部４６は利用許可証を取得要求時に動的に生成するのではなく、あらかじめ利用許可証を生成して非図示のストレージに格納しておき、利用許可証の取得要求時にストレージから利用許可証を読み取って返す機能を有しても良い。

図２０は認証要求命令検出時の処理手順の一例を示すフローチャートである。図１４とは（１）〜（２）の許可出所リスト取得方法が異なる。ここでは（１）〜（２）の処理についてのみ述べる。

利用許可証管理部５６はアプリ出所検査部６５から呼び出され、IPコネクション管理部２４から呼び出される第１コネクション部３３を介してアプリ毎の利用許可証をWebアプリ配布サーバ５から取得する（ステップＳ１０１）。次に、取得した利用許可証を利用許可証分析部６８に渡す。利用許可証分析部６８は受け取った利用許可証を分析し、利用許可証の中から許可出所リストを取り出す（ステップＳ１０２）。さらに許可出所リスト検査部６６に渡して、改ざんの有無の検査を依頼する。

Webアプリ配布サーバ５から取得した利用許可証は、機器操作命令とともに、情報出力装置３に送られる。利用許可証と機器操作命令を受けた情報出力装置３は、利用許可証の内容に基づいて、機器操作命令を受け付けるかどうかを判断する。

このように、第４の実施形態では、情報操作装置１がWebアプリ配布サーバ５から利用許可証を取得し、この利用許可証に含まれる許可出所リストに基づいて、認証要求を行ったWebアプリの出所を検証するため、意図しないWebアプリからの認証要求を情報出力装置３に送信するおそれがなくなる。また、情報操作装置１は、利用許可証によって、Webアプリが正規のWebアプリ配布サーバ５から送信されたものであることを検証できる。

（第５の実施形態）
第１の実施形態ではアプリ認証処理部２３の呼出し元の検証を行っていなかった。アプリ認証処理部２３の実装形態によっては、アプリ認証処理部２３のみを取り出し、アプリ出所情報を偽った不正な情報操作装置１に流用できてしまう。これに対して第５の実施形態では、アプリ認証処理部２３の呼出し元の検証を行い、想定する呼出し元情報と一致するか判定することにより、不正な流用を防ぐことができる。

図２１は第５の実施形態における情報操作装置１の内部構成を示すブロック図である。図２１は図３のアプリ認証処理部２３に呼出し元検出部８１とプラットホーム検証部８２を追加したものである。

呼出し元検出部８１は認証要求時にアプリ認証処理部２３がWebアプリの中のどこから呼び出されたかを判別し、識別子を得る機能を有する。Webアプリは、多数のソフトウエアモジュール（以下、単にモジュールと呼ぶ）の集合体であり、呼出し元検出部８１は、呼出し元モジュール識別子をプラットホーム検証部８２に渡して呼出し、呼出し元が正しいものであるかどうかの判定を依頼する機能を有する。

プラットホーム検証部８２は呼出し元が想定したモジュールか否かを判定する機能を有する。呼出し元検出部８１から呼出し元モジュールの識別子を受け取り、プラットホーム検証部８２は自身が管理する想定する呼出し元情報および実際の呼出し元モジュールの情報を取得して、一致するかどうかの検証を行う。この際の検証方法としては、呼出し元モジュールのハッシュ値を計算して想定するものと一致するかどうかを判定する方法や、モジュールの呼出しの流れ（呼出し元アドレス）を参照し、想定するものと一致するかどうかを判定する方法、呼出し元モジュールのファイル名と一致するかどうかを判定する方法などがある。

本実施形態では、呼出し側、すなわちWebアプリ実行部２１に秘密を格納することなく、不正な呼出し元を排除することが可能となる。

図２２は第５の実施形態における認証要求命令検出時の処理手順を示すフローチャートである。図２２のフローチャートは、図７と比較して、（1）〜（2）のプラットホーム検証処理が入る点が異なる。ここでは（1）〜（2）の処理のみを説明する。

認証要求部５２が認証トークン生成部６１を呼び出した際に、認証トークン生成部６１は呼出し元検出部８１に対して呼出し元の検出を依頼する（ステップＳ１２）。呼出し元検出部８１は、認証トークン生成部６１を呼び出したモジュールを判別し（ステップＳ１１１）、モジュールの識別子を認証トークン生成部６１に対して返す。認証トークン生成部６１はさらに、プラットホーム検証部８２に対して呼出し元検出部８１から受け取ったモジュールの識別子を渡して呼出し元の検証を依頼し（ステップＳ１１２）、プラットホーム検証部８２はモジュールの識別子からモジュールの固有情報（a）を取得する（ステップＳ１１３）。この固有情報としては、モジュールのプログラムのハッシュ値、モジュールが存在する主記憶１３上の呼出し元アドレス、ファイル名などが考えられる。さらにプラットホーム検証部８２は改ざんが困難な領域に予め格納されている固有情報（b）を取得する。さらに呼出し元から取得した固有情報（a）と想定する固有情報（b）が一致するか判定する（ステップＳ１１４）。一致した場合には正しい呼出し元と判定して図７のステップＳ１３〜Ｓ２６の処理を続行し、一致しない場合には不正な呼出し元と判定してエラーを発生させる（ステップＳ１１５）。

このように、第５の実施形態では、認証トークンを生成するアプリ認証処理部２３を偽った不正な情報操作装置１を防止するために、アプリ認証処理部２３がどこから呼び出されたかを検証するプラットホーム検証部８２を設けている。これにより、Webアプリの中のどこからアプリ認証処理部２３が呼び出されたかを特定でき、アプリ認証処理部２３を偽るような不正を防止できる。

（第６の実施形態）
第５の実施形態ではWebアプリ実行部２１に秘密を持たせないことを前提としていたが、Webアプリ実行部２１が秘密情報を持たせることができる場合には、認証によるアプリ認証処理部２３の不正利用防止が実現できる。

図２３は第６の実施形態における情報処理装置の内部構成を示すブロック図である。図２３は図２１と比較して、Webアプリ実行部２１内にプラットホーム検証認証部５７を追加した点で異なる。なお、図２３では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。

プラットホーム検証認証部５７は鍵情報を有し、その鍵を用いてプラットホーム検証部８２と認証を行う機能を有する。この認証方法としては例えばチャレンジ・アンド・レスポンスなど、一般によく知られた方法を使えばよい。認証に用いる鍵情報が盗み取られない限り、プラットホーム検証認証部５７を模倣する操作機器を作ることは困難である。一般に第５の実施形態で述べた完全性検証よりも認証の方が実装コストが低いという特徴があり、Webアプリ実行部２１に秘密を持たせることが出来る、すなわちWebアプリ実行部２１に鍵情報を第三者から読み取り困難に格納できる場合には第６の実施形態を利用する利点がある。

図２４は第６の実施形態における認証要求命令検出時の処理手順を示すフローチャートである。図２４のフローチャートは、図２２と比較して、（1）〜（2）のプラットホーム検証処理が異なる。ここでは（1）〜（2）の処理のみを説明する。

認証要求部５２が認証トークン生成部６１を呼び出した際に認証トークン生成部６１は呼出し元検出部８１に対して呼出し元の検出を依頼する（ステップＳ１２）。呼出し元検出部８１は、認証トークン生成部６１を呼び出したモジュールを判別し（ステップＳ１１１）、モジュールの識別子を認証トークン生成部６１に対して返す。認証トークン生成部６１はまた、モジュールの識別子をプラットホーム検証部８２に渡して、認証要求を出す。プラットホーム検証部８２は渡されたモジュールの識別子で識別されるモジュールのプラットホーム検証認証部５７に対して認証要求を出す（ステップＳ１２１）。プラットホーム検証認証部５７は認証要求に対して自身の持つ鍵を用いて認証に対する返答を実施する（ステップＳ１２２）。この認証方法としては例えばチャレンジ・アンド・レスポンスなど、一般によく知られた方法を使えばよい。プラットホーム検証部８２は認証結果を検査し（ステップＳ１２３）、認証が成功した場合には図７の第２コネクション部３４情報取得以降の処理（ステップＳ１３〜Ｓ２６）を続ける一方、認証が失敗した場合にはエラーを発生させる（ステップＳ１２４）。

このように、第６の実施形態では、Webアプリ実行部２１に秘密情報を持たせることができる場合には、Webアプリ実行部２１内にプラットホーム検証認証部５７を設けることで、認証要求を行ったWebアプリの中のどこからアプリ認証処理部２３が呼び出されたかを特定でき、アプリ実行部２１を偽るような不正を防止できる。

（第７の実施形態）
第１の実施形態では認証トークン生成に用いる鍵の有効性の確認を行っていなかった。認証トークン生成用鍵が盗まれてしまうと、認証トークンの不正生成が可能になり、不正なプラットホームにより情報出力装置３の遠隔操作が可能になってしまう。これに対して第７の実施形態では、認証トークン生成用の鍵の有効性の確認および、不正な鍵のリボーク（無効化）処理を行い、鍵盗用時の脅威に対処することが可能となる。

図２５は第７の実施形態における情報処理装置の内部構成を示すブロック図である。図２５は、図３と比較して、アプリ認証処理部２３内にリボーク検出部８３、鍵無効化部８４および鍵更新部８５を追加した点で異なる。なお、図２５では、PFアプリ実行部２２を省略しているが、図２と同様に、アプリ認証処理部２３はPFアプリ実行部２２の内部に設けられている。

本実施形態においては、鍵管理部６３は図２６に示すように複数の鍵を管理し、鍵番号で区別する。鍵データとして、例えば鍵番号、鍵有効性および鍵情報の情報を持つ。

リボーク検出部８３は鍵の無効（リボーク）を検出する機能を有する。この方法として例えば、情報出力装置３と連携して認証要求時に情報出力装置３は第２コネクション部３４を介してチャレンジとともに、認証に用いる鍵番号を送信し、リボーク検出部８３が与えられた鍵番号未満の鍵を無効と判断する方法や、Webアプリ配布サーバ５に無効化された鍵の番号を問い合わせる機能を有する。

鍵無効化部８４はリボーク検出部８３からリボークされた鍵番号情報を受け取り、実際に鍵を無効にする機能を有する。例えば、図２６は、鍵管理部６３が管理する鍵番号、鍵有効性および鍵情報の対応関係を登録したテーブルを示している。図２６の鍵情報では初期状態として鍵番号0が無効、1,2…Nが有効であるが、リボーク検出部８３から3未満の鍵情報が無効という情報が与えられた場合には、鍵番号1、2の鍵有効性情報について無効という情報を書き込む。

鍵更新部８５はIPコネクション管理部２４とIPコネクション管理部２４から呼び出される第１コネクション部３３を介してWebアプリ配布サーバ５から最新の鍵情報をダウンロードして、署名検証を行い、改ざんが検出されなかった場合には、操作機器に保存される鍵情報を上書きする機能を有する。鍵更新部８５は必須の構成ではない。

図２７は第７の実施形態におけるWebアプリ配布サーバ５の内部構造を示すブロック図である。図２７のWebアプリ配布サーバ５は、図５と比較して、鍵情報提供部４７を追加した点で異なる。

鍵情報提供部４７は、情報操作装置１もしくは情報出力装置３からの鍵情報の取得要求に従って、最新の鍵情報を不図示のWebアプリ配布サーバ５が備えるストレージから取得し、HTTPサーバ処理部４３を介して要求元に送信する機能を有する。

図２８は第７の実施形態における情報出力装置３の内部構造を示すブロック図である。図４の情報出力装置３に鍵更新部７７を備える点が異なる。

鍵更新部７７はIPコネクション管理部７０とIPコネクション管理部７０から呼び出される第１コネクション部７８を介してWebアプリ配布サーバ５に対して最新の鍵情報の取得要求を送信する機能を有する。鍵更新部７７は鍵情報を受け取ると、情報出力装置３の不図示のストレージに格納される鍵情報を受け取った鍵情報で上書きする。鍵更新部７７は情報出力装置３の起動時もしくは定期的に実行され、鍵情報を最新に保つことができる。

図２９は第７の実施形態におけるリボーク処理を含む認証要求時の処理手順を示すフローチャートである。図２９のフローチャートは、図７と比較して、レスポンス生成依頼からレスポンス（認証トークン）生成までの処理が異なるため、異なる処理を中心に説明する。

認証トークン生成部６１はチャレンジ情報に対応するレスポンスの生成依頼を出した（ステップＳ１３１）後、リボーク検出部８３は第２コネクション部３４を介して情報出力装置３から伝えられた鍵番号（Nとする）を取得し（ステップＳ１３２）、その鍵番号未満（0….N-1）の鍵を無効と判定し、鍵無効化部８４を呼び出す。鍵無効化部８４は図２６に示されるような鍵情報について、与えられた鍵番号0….N-1の鍵の鍵有効性情報を無効に書き換える（ステップＳ１３３）。その後、鍵管理部６３は鍵番号Nの鍵情報を取得する（ステップＳ１３４）。アプリ認証処理部２３は取得した鍵情報と受け取ったチャレンジ情報からレスポンスを生成し、認証トークンとして返す（ステップＳ１３５）。

図３０は第７の実施形態における鍵更新時の処理手順を示すフローチャートである。鍵更新部７７は、情報操作装置１の起動時や一定期間ごとに鍵更新処理を行う。鍵更新部７７はまず、IPコネクション管理部７０とIPコネクション管理部７０から呼び出される第１コネクション部７８を介してWebアプリ配布サーバ５から最新鍵データのダウンロードを行う（ステップＳ１４１）。次に、情報操作装置１内に保存されている署名検証用公開鍵を読み込み（ステップＳ１４２）、ダウンロードした鍵データの署名検証を行う（ステップＳ１４３）。改ざんが検出された場合にはエラーを発生させ（ステップＳ１４４、Ｓ１４５）、検出されなかった場合にはダウンロードした鍵データで情報操作装置１内に保存されている図３０に示される形式の鍵データを上書き保存する（ステップＳ１４４、Ｓ１４６）。

このように、第７の実施形態では、Webアプリ配布サーバ５から取得した鍵データを情報操作装置１が所持する署名検証用公開鍵を利用して検証し、検証に成功したら、認証トークン生成用の鍵を更新するようにしたため、安全に鍵の更新作業を行うことができる。

ここで、上述した実施形態に係る発明の利用場面について、説明する。

近年、HTMLやJavaScriptでリッチなクライアントアプリケーション（ウェブアプリケーション）を記述することが一般的になりつつある。これに伴い、デジタルＴＶや携帯電話、スマートフォン等のデジタル機器でも、実行させるアプリケーションソフトウェアをウェブアプリケーションで記述する例が出てきている。デジタルＴＶにおけるIPTVなどはその端的な例であり、ウェブアプリケーションの技術を用いてメニュー画面や動画再生画面を表示する規格が登場している。

このウェブアプリケーションはHTMLやJavaScriptなどが解釈できるブラウザベースの実行環境で実行される。このウェブアプリケーションは、一般に複数のページファイルとメディアファイルとで構成される。ここでいうメディアファイルとは、JPEG、GIF、MPEGなどの動画像データを格納するファイルや、MP3などの音声データを格納するファイルのことをいう。一方、ページファイルには、HTMLなどで記述される文字や画像等の配置情報と表示文字データなどに加えて、JavaScriptのような制御プログラム情報が格納される場合がある。また、JavaScriptは、HTTP（XMLHTTPRequest）やWebSocketと呼ばれるプロトコルで、HTTPサーバやWebSocketサーバと通信することができる。

HTTPサーバやWebSocketサーバは、サーバ上の機器が備える各種機能を操作するインタフェースを搭載することにより、機器の遠隔操作を行えるようになる。例えばデジタルＴＶにWebSocketサーバを搭載し、そのWebSocketプロトコルを介してチャンネル変更や録画予約機能を行えるようにした場合には、例えばタブレット端末のブラウザで動作するウェブアプリケーションからチャンネル変更や録画予約などの遠隔操作を行えるようになる。

タブレット端末等の情報操作装置から、デジタルＴＶ等の情報出力装置の各種機能を操作するための機器操作命令を無線送信して、情報出力装置を遠隔操作する場合、情報操作装置は、ウェブサーバにアクセスして、機器操作命令が記述されたウェブアプリケーションを取得して実行し、その実行結果に基づいて、機器操作命令を情報出力装置に送信することになる。

したがって、情報操作装置が実行するウェブアプリケーションが信頼のおけるものでないと、情報出力装置が勝手に操作されてしまうことになる。そのような場合に、上述した実施形態に係る発明は、ユーザの許諾なしに情報出力装置が勝手に操作されることを防止しつつ、情報操作装置から情報出力装置を操作できるようにして利便性を向上させることができる。

上述した実施形態で説明した情報操作装置１および情報出力装置３の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報操作装置１および情報出力装置３の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、情報操作装置１および情報出力装置３の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１情報操作装置、３情報出力装置、５ Webアプリ配布サーバ、２１ Webアプリ実行部、２３アプリ認証処理部、２４ IPコネクション管理部、２５入力受信部、２６ HTTP処理部、２７アプリ出所付与部、２８機器検索処理部、３３第１コネクション部、３４第２コネクション部、３５第３コネクション部、３６第４コネクション部、５１ページ実行部、５２認証要求部、５３操作命令生成部、５４操作命令送信部、５５認証トークン送信部、６１認証トークン生成部、６２開始アプリURL管理部、６３鍵管理部、６４認証処理部、７０ IPコネクション管理部、７１メッセージ分析部、７２認証用チャレンジ生成部、７３認証トークン検査部、７４機器操作命令処理部、７５アプリ出所検査部、７６機器検索応答部、７７鍵更新部、７８第１コネクション部

Claims

第１通信装置からウェブアプリケーションを取得するための接続確立処理を行い、前記ウェブアプリケーションを受信する第１コネクション部と、
前記第１コネクション部を介して前記第１通信装置から受信した前記ウェブアプリケーションを実行して機器操作命令を生成するウェブアプリ実行部と、
ウェブアプリケーションから認証要求を受けると、前記第２通信装置に認証要求を送信するとともに、これに応答して前記第２通信装置から送信された認証要求子を受信するための接続確立処理を行い、認証要求子を受信する第２コネクション部と、
前記第２コネクション部を介して前記第２通信装置から受信した前記認証要求子を、前記第２通信装置との間で共有する共通鍵とユーザが入力した鍵情報に基づいて暗号化したプラットホーム認証子を生成するアプリ認証処理部と、
前記プラットホーム認証子に前記ウェブアプリケーションの出所情報を付与するアプリ出所情報付与部と、
前記第２通信装置に、前記機器操作命令と前記出所情報が付与されたプラットホーム認証子とを送信するための接続確立処理を行い、前記機器操作命令と前記出所情報が付与されたプラットホーム認証子とを送信する第３コネクション部と、を備えることを特徴とする情報操作装置。
前記第２通信装置を検索するための機器検索命令を送信するための接続確立処理を行うとともに、確立したコネクションを利用して機器検索命令を送信する第４コネクション部と、
前記機器検索命令に応答して前記第２通信装置から送信された前記第２通信装置の位置識別情報を、前記第４コネクション部を介して受信する機器検索処理部と、を備え、
前記第２コネクション部および前記第３コネクション部は、前記位置識別情報に基づいて、前記位置識別情報を送信した前記第２通信装置との間でそれぞれの接続確立処理を行うことを特徴とする請求項１に記載の情報操作装置。
前記プラットホーム認証子の生成命令の発行を行うことが可能なウェブアプリケーションの取得先をリストアップした許可出所リストを取得する許可出所リスト取得部と、
前記第１コネクション部を介して取得したウェブアプリケーションの取得先が前記許可出所リストに含まれるか否かを検証するアプリ出所検証部と、を備え、
前記アプリ認証処理部は、前記アプリ出所検証部により含まれないと検証されると、前記プラットホーム認証子の生成を禁止することを特徴とする請求項１または２に記載の情報操作装置。
前記許可出所リストに付属する署名が正しいか否かを署名検証用公開鍵で検証する許可出所リスト検査部を備え、
前記アプリ認証処理部は、前記許可出所リスト検査部により前記署名が正しくないと検証されると、前記プラットホーム認証子の生成を禁止することを特徴とする請求項３に記載の情報操作装置。
前記ウェブアプリ実行部は、前記ウェブアプリケーションが正規の前記第１通信装置から送信されたものであることを証明する利用許可証を前記第１コネクション部を介して取得し、
前記許可出所リスト取得部は、前記利用許可証の中に含まれる前記許可出所リストを取得することを特徴とする請求項３または４に記載の情報操作装置。
前記許可出所リストは、前記ウェブアプリケーションのそれぞれごとに設けられることを特徴とする請求項４または５に記載の情報操作装置。
前記許可出所リスト取得部は、前記第１通信装置から送信された最新の前記許可出所リストを前記第１コネクション部を介して定期的に受信して、前記許可出所リストを更新することを特徴とする請求項３乃至６のいずれかに記載の情報操作装置。
前記ウェブアプリ実行部を識別する情報と、前記ウェブアプリ実行部が前記ウェブアプリケーションを実行する手順との少なくとも一方が予め想定されたものと一致するか否かを検証するプラットホーム検証部を備え、
前記アプリ認証処理部は、前記プラットホーム検証部により一致すると検証された場合のみ、前記プラットホーム認証子を生成することを特徴とする請求項１乃至７のいずれかに記載の情報操作装置。
前記プラットホーム認証子を生成するのに用いる前記共通鍵の有効性を前記第１通信装置に問い合わせるリボーク検出部と、
前記リボーク部の問合せに応答して、前記第１通信装置から無効である旨の情報を受信した場合には、前記共通鍵の無効化処理を行う鍵無効化部と、を備えることを特徴とする請求項１乃至８のいずれかに記載の情報操作装置。
前記プラットホーム認証子を生成するのに用いる前記共通鍵の鍵情報を、前記第１コネクション部を介して前記第１通信装置から受信して、前記鍵情報に基づいて前記共通鍵の無効化処理を行う鍵無効化部を備えることを特徴とする請求項１乃至８のいずれかに記載の情報操作装置。
プラットホーム認証子の生成命令の発行を行うことが可能なウェブアプリケーションの取得先をリストアップした許可出所リストを第１通信装置から取得するための接続確立処理を行う第１コネクション部と、
前記情報操作装置からの認証要求に対応した認証子に応答して、前記情報操作装置に認証要求子を送信するための接続確立処理を行う第２コネクション部と、
前記情報操作装置からの機器操作命令およびプラットホーム認証子を受信するための接続確立処理を行う第３コネクション部と、
前記情報操作装置から送信された前記第３コネクション部の接続要求に含まれるウェブアプリケーションの出所情報が前記許可出所リストに登録されているか否かを検証する許可出所検証部と、
前記情報操作装置から送信された前記認証子が認証子リストに登録されているか否かを検証する認証子検証部と、
前記許可出所検証部で登録されていると検証され、かつ前記認証子検証部で登録されていると検証された場合に、前記第２コネクション部を介して前記情報操作装置からの前記機器操作命令を受信する制御を行うコネクション管理部と、を備えることを特徴とする情報出力装置。
第１通信装置からウェブアプリケーションを取得するための接続確立処理を行い、前記ウェブアプリケーションを受信するステップと、
前記第１通信装置から受信した前記ウェブアプリケーションを実行して機器操作命令を生成するステップと、
ウェブアプリケーションから認証要求を受けると、前記第２通信装置に認証要求を送信するとともに、これに応答して前記第２通信装置から送信された認証要求子を受信するための接続確立処理を行い、認証要求子を受信するステップと、
前記第２通信装置から受信した前記認証要求子を、前記第２通信装置との間で共有する共通鍵とユーザが入力した鍵情報に基づいて暗号化したプラットホーム認証子を生成するステップと、
前記プラットホーム認証子に前記ウェブアプリケーションの出所情報を付与するステップと、
前記第２通信装置に、前記機器操作命令と出所情報が付与されたプラットホーム認証子を送信するための接続確立処理を行い、前記機器操作命令と前記出所情報が付与されたプラットホーム認証子を送信するステップと、をコンピュータに実行させるコンピュータ読み込み可能な情報操作プログラム。