JP6668183B2 - 通信装置、通信方法、通信システムおよびプログラム - Google Patents

Description

本発明の実施形態は、通信装置、通信方法、通信システムおよびプログラムに関する。

インターネット上でＷｅｂサービスを提供するＷｅｂサーバが、ユーザのＷｅｂブラウザを介して、ローカルネットワーク上の機器で動作するサーバ（以降、単に機器と呼ぶ）と、相互認証に基づいた暗号化通信を行うことは難しい。具体的には、以下の３つの問題がある。

［１］Ｗｅｂブラウザ（および、Ｗｅｂサーバのフロントエンド）が、ローカルネットワーク上の機器を発見することができない。
［２］機器が正規のサーバ証明書を持っていない。すなわち、当該ローカルネット上の機器が、信頼できる機器であることを、Ｗｅｂブラウザ（およびＷｅｂサーバのフロントエンド）が検証できない。
［３］機器が、Ｗｅｂサーバおよびユーザに対する認証・アクセス制御を行うことができない。

［１］の解決策としては、ユーザが予め機器のＩＰアドレスを把握しておき、Ｗｅｂサーバ側がこのＩＰアドレスを把握するための登録インタフェースを備えておく。そして、このＩＰアドレスをＷｅｂサーバに設定することで、Ｗｅｂサーバから機器へのアクセスを実現することができる。
［２］の解決策としては、ユーザが自身で認証局を立ち上げ、その認証局による署名付きのルート証明書を作成し、ルート証明書をＷｅｂブラウザに、信頼できるものとして登録する。そして、ユーザ自身で認証局による署名付きのサーバ証明書を作成し、これを機器に設定する。これにより、ユーザは、当該機器が、信頼できる機器であるとＷｅｂブラウザに認識させることができる。
［３］の解決策としては、機器に予めユーザＩＤ、パスワードを設定し、Ｗｅｂブラウザが機器にアクセスする際に、ＩＤ／パスワード認証をかけることで、アクセス制御を行うことができる。

しかしながら、いずれの場合も、ユーザに対して手動設定作業を強いるものであり、ユーザビリティ上の問題がある。また、［２］および［３］については、それぞれＷｅｂサーバが機器を正当なものとして、また、機器がＷｅｂサーバを正当なものとして、検証できていない。具体的には、両者が正規の認証局が発行したサーバ証明書を持つサーバであることを検証できていない。このため、悪意あるユーザによって、いずれか一方がｅｖｉｌであっても、両者間で容易に通信させることができてしまう。

［２］の問題は、機器が、信頼できるサーバ証明書を持っていないことが主な原因である。しかしながら、正規の認証局は、グローバルアクセス可能なドメインを持ち、かつ、管理主体が明確なサーバに対して、証明書を発行することが一般的である。正規の認証局が、ローカルネットワーク上の機器に対して、正規のサーバ証明書を発行する方法は知られていない。

関連技術として、機器に対する証明書を発行する方法がある。しかしながら、この技術は、機器のためのクライアント証明書を発行する方法であって、機器がサーバとして振る舞う場合に、これに安全にアクセスするためのサーバ証明書を発行する方法に関するものではない。

ローカルネットワーク上の機器がサーバとして振る舞う場合、当該サーバは、プライベートアドレス空間に属し、かつ変化し得るＩＰアドレスを持つ。このようなサーバに対して、固定的な名前をどの時点で付与するのか、その名前に対する証明書をどのように発行するのか等、関連技術では、解決できない問題がある。

特開２０１２−０４９７５２号公報

本発明の実施形態は、ネットワーク上の機器に、安全にアクセスできるようにする通信装置、通信方法、通信システムおよびプログラムを提供する。

本発明の実施形態としての通信装置は、第１ネットワークを介して、サーバと通信可能な第１通信部と、第２ネットワークを介して、ユーザの操作端末と通信可能な第２通信部と、第１処理を実行する第１通信処理部と、前記第２通信部を介して、署名対象データを含む発行要求を受信し、前記第１通信処理部の識別情報と、第１鍵および前記第１鍵と対になる第２鍵を用いて、前記第１通信処理部の識別情報と前記第１鍵とを含み、前記第２鍵により署名された証明書を発行し、また、前記署名対象データを第３鍵で署名した署名データを生成し、前記署名データと前記証明書とを、前記第２通信部を介して送信する、第２通信処理部と、前記証明書の発行を前記ユーザが許可したことを表す許可情報を取得する認可部を備える。前記第１通信処理部は、前記第１通信部を介して、前記第１処理の実行を要求する命令を受信した場合に、前記証明書を用いて、前記命令の送信元と認証処理を行う。前記第２通信処理部は、前記許可情報が取得された場合のみ、前記証明書が発行または用いられるよう制御する。

第１実施形態に関わる通信装置を備えたシステムの全体構成を示す図。 第１実施形態に係る通信シーケンスを示す図。 第１実施形態に係る通信装置の動作のフローチャート。 第２実施形態に係るシステムの通信シーケンスを示す図。 機器の表示部に表示される認可ダイアログの例を示す図。 第２実施形態に係る通信装置の動作のフローチャート。 第３実施形態に係る通信装置を備えたシステムの全体構成を示す図。 第３実施形態に係るシステムの通信シーケンスを示す図。 操作端末のＷｅｂブラウザに表示される認可画面の例を示す図。 通信装置が搭載されたＳＤカードを、操作端末に挿入した状態を示す図。 操作端末からＳＤカードを抜いて、レガシー機器に挿入した状態を示す図。 第４実施形態に係るシステムの通信シーケンスを示す図。 第５実施形態に係るシステムの通信シーケンスを示す図。

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

＜第１実施形態＞
図１は、第１実施形態に関わる通信装置１０１を備えたシステムの全体構成を示す。

通信装置１０１は、ユーザによって所有される機器１００に搭載されている。本実施形態では機器が、デジタルテレビ（以下、テレビと呼ぶ）である場合を想定するが、これに限定されない。例えば、通信装置が、他の家電機器や、住宅設備機器、工場・ビル設備機器のような別の種類の機器に搭載されてもよい。機器は、表示部やテレビ用チューナ等のテレビとして必要な機能を備えている。通信装置１０１は、Ｗｅｂサーバ３０１および操作端末２０１と通信する手段（第１通信部１１１および第２通信部１１４）を備えている。

操作端末２０１は、ユーザが操作する端末装置（ユーザ端末）である。操作端末２０１は、一例として、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、スマートフォン、または、タブレットなどである。操作端末２０１には、Ｗｅｂサーバ３０１が提供するＷｅｂサービスにアクセスするためのＷｅｂブラウザが搭載されている。本実施形態では、操作端末２０１がスマートフォンであると想定する。ユーザは、Ｗｅｂブラウザを介して、Ｗｅｂサーバ３０１が提供するＷｅｂサービスを利用することで、通信装置１０１にアクセスする。

操作端末２０１は、第１ネットワーク５０１および第３ネットワーク７０１を介して、Ｗｅｂサーバ３０１と接続されている。また、操作端末２０１は、第２ネットワーク６０１を介して、通信装置１０１の第２通信部１１４と接続されている。また、操作端末２０１は、第１ネットワーク５０１を介して、通信装置１０１の第１通信部１１１と接続されている。また、Ｗｅｂサーバ３０１は、第３ネットワーク７０１および第１ネットワーク５０１を介して、通信装置１０１の第１通信部１１１と接続されている。また、Ｗｅｂサーバ３０１は、第３ネットワーク７０１を介して、機器登録サーバ４０１と接続されている。

第１ネットワーク５０１は、宅内、オフィス、工場などのローカルネットワークである。通信の媒体は、イーサネット（登録商標）または無線ＬＡＮ等、上位でＩＰ通信を実現できるものを想定しているが、媒体および上位の通信プロトコルはこれらに限定されない。本実施形態では、第１ネットワーク５０１は、無線ＬＡＮで構築されたホームネットワークであるとする。

第２ネットワーク６０１は、操作端末２０１が通信装置１０１と安全に（情報漏洩せずに）通信可能なネットワークである。具体的には、通信装置１０１と操作端末２０１を直接接続するＵＳＢ、ＨＤＭＩ（登録商標）、ＳＤＩＯ、あるいは、ＮＦＣ等の近接無線、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）など安全性の高い近距離無線通信などである。本実施形態では、操作端末２０１は、通信装置１０１とＢＬＥで接続されている場合を想定する。

第３ネットワーク７０１は、インターネット等のＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。操作端末２０１とＷｅｂサーバ３０１間の通信、および、Ｗｅｂサーバ３０１と機器登録サーバ４０１間の通信は、この第３ネットワーク７０１を介して行われる。本実施形態では、第３ネットワーク７０１はインターネットの場合を想定する。

Ｗｅｂサーバ３０１は、インターネット上でＷｅｂサービスを提供する、グローバルにアクセス可能なサーバである。Ｗｅｂサーバ３０１の実体は、物理マシンか仮想マシンかを問わない。Ｗｅｂサーバ３０１は、一例としてＨＴＴＰサーバであることを想定する。Ｗｅｂサーバ３０１は、フロントエンドと、バックエンドを有する。フロントエンドは、ＨＴＭＬ／ＣＳＳ／ＪａｖａＳｃｒｉｐｔ（登録商標）等で構成されたＷｅｂサービスが提供するＷｅｂページのことである。バックエンドは、Ｗｅｂサーバ３０１が提供するＷｅｂサービスの主機能（サーバ機能）を行う部分である。ただし、Ｗｅｂサーバ３０１のプロトコルや機器構成はこれらに限定されない。

Ｗｅｂサーバ３０１が提供するＷｅｂサービスは、操作端末２０１を介して、第１ネットワーク５０１上の機器１００（または通信装置１０１）を発見し、機器１００が提供する機能を、ユーザに提供する。これらの動作は、操作端末２０１のＷｅｂブラウザで表示したＷｅｂページを介して行う。

通信装置１０１は、機器（ここではテレビ）の機能として、テレビリモコン機能を提供する。Ｗｅｂサービスが、操作端末２０１のＷｅｂページを介して、このテレビリモコン機能の操作の依頼を受け付ける。ユーザは、Ｗｅｂページでリモコン指示を入力することで、Ｗｅｂサービスを介して、テレビを操作することができる。つまり、ユーザは、自身の操作端末２０１のＷｅｂブラウザで表示されているテレビリモコンサービスのＷｅｂ画面を通して、自身が所有するテレビを操作する。ユーザの入力したリモコン指示はＷｅｂブラウザからフロントエンドおよび第１ネットワーク５０１を介して通信装置１０１に送信される。通信装置１０１がこの実行要求を実行することで、ユーザによるテレビのリモコン操作が実現される。

機器登録サーバ４０１は、第３ネットワーク７０１（インターネット等）上に展開されたＨＴＴＰサーバである。機器登録サーバ４０１の実体は、物理マシンか仮想マシンかを問わない。機器特録サーバのプロトコルや機器構成は、これらに限定されない。機器登録サーバ４０１は、Ｗｅｂサーバからの要求（後述のローカルサーバ検証要求）を受けて、チャレンジコード（署名対象データ）を生成する機能を有する。また、機器登録サーバ４０１は、通信装置１０１により生成された署名コード（署名データ）を、Ｗｅｂサーバを介して受信し、通信装置１０１との事前共有鍵を用いて、当該署名コードを検証する。具体的に、受信した署名コードが、チャレンジコードを事前共有鍵で署名したものに一致するか、あるいは、署名コードを事前共有鍵で復号したデータが、チャレンジコードに一致するかを判断する。

上述のように、機器登録サーバ４０１は、通信装置１０１との間で秘密鍵である事前共有鍵を共有している。機器登録サーバ４０１の運営事業者は、通信装置１０１の情報秘匿レベルや、対応プロトコルを検査した上で、通信装置１０１に対して、事前共有鍵を発行する。情報秘匿レベルの例として、セキュアエレメントを搭載し、事前共有鍵が漏洩しない対策が施されているか否か等がある。対応プロトコルの例として、後述する鍵ペア（秘密鍵および公開鍵）およびサーバ証明書の作成や授受の方式が、機器登録サービスがサポートする規格に対応しているか否か等がある。通信装置１０１または機器１００の製造者は、事前共有鍵を安全な記憶領域に書き込んで出荷する。なお、事前共有鍵は、通信装置１０１または機器１００の型番（機種）単位で発行されるものとするが、発行単位には様々なバリエーションがある。例えば、事前共有鍵は、通信装置１０１または機器１００の個別機器単位でユニーク、複数機種にまたがった製品シリーズ単位でユニークでもよい。事前共有鍵の実現形態は問わない。

通信装置１０１は、第１通信部１１１と、第１通信処理部１１２と、第１記憶部１１３と、第２通信部１１４と、第２通信処理部１１５と、第２記憶部１１６と、設定部１１７と、認可部１１８とを備える。

第１通信部１１１は、第１ネットワーク５０１を介して、Ｗｅｂサーバ３０１および操作端末２０１と通信する通信モジュールである。本実施形態では、第１通信部１１１は、Ｗｉ−Ｆｉの送受信部であるとする。第１通信部１１１は、一例として通信回路によって構成される。通信回路は、ハードウェアのみによって構成されてもよいし、ハードウェアとソフトウェアによって構成されてもよい。

第１通信処理部１１２は、第１通信部１１１を介して、操作端末２０１（より詳細には操作端末２０１上のＷｅｂブラウザ）に、機器のリソース（リモコン機能等）を提供する。このリソースの提供は、一例として、第１通信処理部１１２による第１処理の実行に相当する。第１通信処理部１１２は、操作端末２０１のＷｅｂブラウザを介して、Ｗｅｂサーバ３０１のフロントエンドからアクセスされる。第１通信処理部１１２は、ＨＴＴＰサーバであることを想定するが、Ｗｅｂブラウザでサポートされている限り、他のプロトコル（ＣｏＡＰ、ＭＱＴＴ等）でもよい。

第１記憶部１１３は、第１通信部１１１および第１通信処理部１１２の動作に係る設定情報（ＨＴＴＰサーバの設定ファイル等）を記憶する。第１記憶部１１３は、不揮発性メモリ等の不揮発記憶装置である。第１記憶部１１３の例として、ＳＳＤ、ハードディスク、ＦＲＡＭ（登録商標）等がある。ただし、第１記憶部１１３の形態は、これらに限定されない。

第２通信部１１４は、第２ネットワーク６０１を介して、操作端末２０１と通信する通信モジュールである。前述した通り、本実施形態では、第２通信部１１４は、ＢＬＥの送受信部であるとする。第２通信部１１４は、一例として通信回路によって構成される。通信回路は、ハードウェアのみによって構成されてもよいし、ハードウェアとソフトウェアによって構成されてもよい。

第２通信処理部１１５は、第２通信部１１４を介して、操作端末２０１（より詳細には操作端末２０１上のＷｅｂブラウザ）と通信する。第２通信処理部１１５は、後述する通信シーケンスを実現する主機能を有する。具体的に、第２通信処理部１１５は、操作端末２０１からの探索要求に応じて、機器の情報を提供する。また、第２通信処理部１１５は、Ｗｅｂブラウザからの要求に応じて、鍵ペア（公開鍵と秘密鍵）を生成し、秘密鍵を第１記憶部１１３に記憶し、公開鍵を提供する機能を有する。公開鍵で暗号化されたデータは、秘密鍵のみで復号可能であり、秘密鍵で暗号化されたデータは、公開鍵のみで復号可能である。第２通信処理部１１５は、この基本的な機能を用い、さらに、ユーザからの認可に基づき、サーバ証明書ないし証明書署名要求を発行する機能を備える。本実施形態では、サーバ証明書を発行するものとする。

第２記憶部１１６は、第２通信部１１４および第２通信処理部１１５の動作に係る設定情報（機器登録サーバ４０１との事前共有鍵等）を記憶する。なお、事前共有鍵を第１記憶部１１３に記憶させてもよい。第２記憶部１１６は、不揮発性メモリ等の不揮発記憶装置である。第２記憶部１１６の例として、ＳＳＤ、ハードディスク、ＦＲＡＭ等があるが、これらに限定されない。第２記憶部１１６は、第１記憶部１１３と物理的に同一のものでも、異なるものでも構わない。

設定部１１７は、第２通信処理部１１５の指示に基づき、第１通信処理部１１２の設定および変更を行う。また、設定部１１７は、第１記憶部１１３に対して書き込み、および読み出し可能である。

認可部１１８は、機器が備えるインタフェースを介して、Ｗｅｂサービスから通信装置１０１へのアクセス認可を示す操作をユーザから受け付ける機能を有する。認可部１１８は、ユーザの認可を受けると、ユーザ認可が得られたことを示す許可情報を第２通信処理部１１５に出力する。

図２に、第１実施形態に係る通信シーケンスを示す。本通信シーケンスでは、以下のユーザシナリオを想定する。

宅内にいるユーザが、第３ネットワーク７０１（インターネット等）上のＷｅｂサーバ３０１が提供するＷｅｂサービス（テレビリモコンサービス）に、操作端末２０１上のＷｅｂブラウザからログインする。Ｗｅｂサーバ３０１のフロントエンドは、ブラウザ上にＷｅｂページを提供する。Ｗｅｂサーバ３０１のフロントエンドが、第１ネットワーク５０１（宅内ＬＡＮ）上の機器（テレビ）を探索および発見する。ユーザが、Ｗｅｂサービスに対し機器１００（より詳細には通信装置１０１）へのアクセスを認可すると、以降、ユーザはＷｅｂページを介して、通信装置１０１が提供するリソースの機能（テレビのリモコン操作）を実行できる。

前提条件として、通信装置１０１の第１記憶部１１３に、型番単位で、機器登録サーバ４０１によって生成された事前共有鍵が記憶されている。第１記憶部１１３は、通信装置１０１の外部からはアクセスできないセキュアな領域である。また、通信装置１０１の第２通信部１１４と、操作端末２０１とには、ＢＬＥ通信機能が搭載されている。また、Ｗｅｂブラウザには、第２ネットワーク６０１における周辺のＢｌｕｅｔｏｏｔｈ機器を発見する機能（Ｗｅｂ Ｂｌｕｅｔｏｏｔｈ ＡＰＩ）が搭載されている。

ユーザが、操作端末２０１のＷｅｂブラウザから、Ｗｅｂサーバ３０１が提供するＷｅｂサービスにアクセスし、ユーザＩＤとパスワードを含むログイン要求を送信する（ステップ１）。

Ｗｅｂサーバ３０１のフロントエンドは、ログイン要求をバックエンドに送る（ステップ２）。バックエンドは、ユーザ認証を行い、ユーザ認証が成功することで、ログインセッションに入る。このとき、バックエンドは、セッションＩＤ（ｓｅｓｓｉｏｎＩＤ）を発行し、ユーザ情報に関連づけて管理する。バックエンドは、セッションＩＤを、フロントエンドに送る（ステップ２ｆ）。ただし、ログインセッションの実現形態は、これに限定されるものではない。Ｗｅｂサービスのフロントエンドとバックエンド間の通信は、一般的にはＴＬＳで暗号化されている。

フロントエンドは、セッションＩＤを含むユーザ情報取得要求を、バックエンドに送る（ステップ３）。バックエンドは、セッションＩＤに関連づけられたユーザ情報を特定し、フロントエンドに送る（ステップ３ｆ）。ユーザ情報は、Ｗｅｂサービス内でユーザを一意に識別可能なユーザＩＤまたはｅ−ｍａｉｌアドレス等である。図では、ユーザ情報をｕｓｅｒ＿ｉｄと表している。

ユーザ情報は、ステップ２ｆで、セッションＩＤとともに送られてもよい。あるいは、後述するローカルサーバ検証要求の応答（ステップ８ｆ）として、チャレンジコード（ｃｏｄｅ）と共に送信されてもよい。ここで述べた以外の方法で、ユーザ情報をフロントエンドに提供してもよい。

フロントエンドは、操作端末２０１のＷｅｂブラウザ上に実装されたＷｅｂ Ｂｌｕｅｔｏｏｔｈ ＡＰＩに対して、周辺ＢＬＥ機器の発見要求を送信する（ステップ４）。

操作端末２０１のＷｅｂブラウザは、発見要求を受けて、周辺の機器（ここではＢＬＥ機器）を探索し（ステップ５）、応答を受けることで、機器１００を発見する（ステップ５ｆ）。ここでは、機器１００として、テレビを発見する。Ｗｅｂブラウザは、発見した機器１００の情報を、Ｗｅｂサーバ３０１に送信する（ステップ４ｆ）。

Ｗｅｂサーバ３０１のフロントエンドは、操作端末２０１のＷｅｂブラウザに、発見した機器１００（テレビ）の情報を表示する（ステップ６）。これにより、ユーザに、Ｗｅｂサービスからテレビへのアクセスの承諾・拒否の判断を促す。複数の機器が存在する場合は、選択画面で、ユーザに対象とする機器を選択させてもよい。

ユーザは、Ｗｅｂブラウザに表示されている許諾ボタンを押下することで、Ｗｅｂサービスから機器１００（テレビ）へのアクセスを認可する。許諾情報がＷｅｂブラウザからＷｅｂサーバ３０１に送信される（ステップ７）。これによりＷｅｂサーバ３０１は、ユーザによりアクセスが認可されたことを認識する。

Ｗｅｂサーバ３０１のフロントエンドは、バックエンドを介して、機器登録サーバ４０１に、発見した機器１００の検証要求（ローカルサーバ検証要求）を送信する（ステップ８、ステップ９）。検証とは、機器１００が、機器登録サーバ４０１に正しく登録された、事前共有鍵を持った通信装置１０１（機器）であることを確認することである。なお、機器登録サーバ４０１とＷｅｂサーバ３０１との間には、事前に信頼関係が構築されているものとする。具体的には、ＯＡｕｔｈにおける認可サーバとＲＰ（Ｒｅｌｙｉｎｇ Ｐａｒｔｙ）の関係と同様に、機器登録サーバ４０１が、予めＷｅｂサーバ３０１にクレデンシャル（識別情報と秘密鍵）を発行しておき、これに基づいて、機器登録サーバ４０１が、Ｗｅｂサーバ３０１を認証し、通信を暗号化するように構成してもよい。

機器登録サーバ４０１は、検証要求を受けて、ランダム文字列であるチャレンジコード（署名対象データ）を発行し、Ｗｅｂサーバ３０１に送信する（ステップ９ｆ）。図では、チャレンジコードを、ｃｏｄｅと表している。Ｗｅｂサーバ３０１は、このチャレンジコードをバックエンドで受信し、フロントエンドに送る。このとき、機器登録サーバ４０１は、通信装置１０１がチャレンジコードへの署名に用いるアルゴリズムの候補リスト（署名アルゴリズムリスト）をＷｅｂサーバ３０１に送信してもよい。この場合、Ｗｅｂサーバ３０１は、この署名アルゴリズムリストとチャレンジコードとを、バックエンドで受信し、フロントエンドに送る。ここでは署名アルゴリズムリストもＷｅｂサーバ３０１に送られたとする。なお、後述するように、機器登録サーバ４０１は、機器１００が事前共有鍵を用いて、チャレンジコード（ｃｏｄｅ）に署名したデータである署名コードを受信および検証することで、機器１００のバリデーションを行う。

フロントエンドは、ＪａｖａＳｃｒｉｐｔ ＡＰＩを介して、Ｗｅｂブラウザに、チャレンジコード（ｃｏｄｅ）と、Ｗｅｂサービスを識別するオリジン情報（ｏｒｉｇｉｎ）と、ユーザ情報（ｕｓｅｒ＿ｉｄ）と、署名アルゴリズムリストと、を含む証明書発行要求を送信する（ステップ１０）。オリジン情報は、ここでは、ｈｔｔｐｓ：／／ｔｖｃｏｎｔｒｏｌ．ｃｏｍであるとする。なお、オリジン情報の一部である「ｔｖｃｏｎｔｒｏｌ．ｃｏｍ」はドメインに相当する。また、ユーザ情報は、識別情報以外の表示名など、その他の属性が含まれていてもよい。

Ｗｅｂブラウザは、第２ネットワーク６０１を介して、第２通信処理部１１５に、当該証明書発行要求をフォワードする（ステップ１１）。

第２通信処理部１１５は、証明書発行要求を受信すると、ＲＳＡ等の公開鍵暗号アルゴリズムを利用して、秘密鍵（ｓｅｃｒｅｔ）と公開鍵（ｐｕｂ）とを含む鍵ペアを生成する（ステップ１２）。また、第２通信処理部１１５は、鍵ペアを識別するための鍵ＩＤを生成する。一例として、鍵ペアは、Ｗｅｂサービスとユーザの組合せごとに生成される。この場合、組合せごとに、異なる鍵ＩＤが付与される。

Ｗｅｂサービスとユーザの組合せにかかわらず単一の鍵ペアを使い回す場合には、鍵ＩＤを生成しなくてもよい。この場合、鍵ペアの生成を、証明書発行要求の受信（ステップ１１）をトリガに実行する必要もない。証明書発行要求の初回の受信時にのみ、鍵ペアを生成してもよい。本実施形態では、Ｗｅｂサービスとユーザの組合せ毎に、異なる鍵ペアを生成する場合を想定する。

第２通信処理部１１５は、第１通信処理部１１２の識別情報を利用して、鍵ペアから、サーバ証明書（ｃｅｒｔ）を生成する（ステップ１３）。第１通信処理部１１２の識別情報の例として、ローカルＩＰｖ４アドレス、またはＩＰｖ６アドレス等を用いることができる。ＩＰアドレス以外の識別情報、例えばＭＡＣアドレス、または無線ＬＡＮプロトコルで通信装置１０１に割り当てられる識別子などを用いることも可能である。また、本実施形態では、操作端末と機器（テレビ）が分離している構成をとっているが、機器と操作端末が一体となっているケース（テレビがＷｅｂブラウザを搭載し、ユーザがテレビのＷｅｂブラウザを介してＷｅｂサービスのＷｅｂ画面を表示しているケース）では、機器識別情報として、ｌｏｃａｌｈｏｓｔやループバックアドレス（１２７．０．０．１）等、機器の内部で一意かつ唯一のホスト名やアドレスを用いてもよい。サーバ証明書の具体的な形式やバージョンは、問わないが、ここではＸ．５０９形式の自己署名証明書を想定する。サーバ証明書は、一例として、種々の属性、公開鍵、および秘密鍵による署名を含む。

ここで、第２通信処理部１１５は、サーバ証明書の発行者属性に、オリジン情報（ｏｒｉｇｉｎ）およびユーザ情報（ｕｓｅｒ＿ｉｄ）のいずれか、ないし、両方を設定する。また、サーバ証明書の発行対象属性に、第１通信処理部１１２の識別情報を設定する。本実施形態においては、自己署名証明書を発行する形態を採るため、発行者属性を用いるか否かは任意である。

第２通信処理部１１５は、設定部１１７に、サーバ証明書および秘密鍵を、第１通信処理部１１２に設定することを指示する（ステップ１４）。設定部１１７は、当該指示を受けてサーバ証明書および秘密鍵の設定を行う（同ステップ１４）。

また、第２通信処理部１１５は、必要に応じて、設定部１１７に、第１通信処理部１１２に、ＣＯＲＳ（Ｃｒｏｓｓ Ｏｒｉｇｉｎ Ｒｅｓｏｕｒｃｅ Ｓｈａｒｉｎｇ）（特定のオリジンからのアクセス認可）設定を行うことを指示する。設定部１１７は、当該指示を受けてＣＯＲＳの設定を、第１通信処理部１１２に行う。具体的には、オリジン情報をホワイトリストに登録する。第１通信処理部１１２は、ホワイトリストに登録されたオリジン情報からのアクセスは、機器のオリジンと異なるオリジンからのアクセスでも許可する。

第１通信処理部１１２への設定には、第１通信処理部１１２の再起動または設定再読込命令などの制御を伴うことが一般的であり、設定部１１７は、必要に応じて、第１通信処理部１１２に対して当該制御を行う。

第２通信処理部１１５は、上記の設定が完了すると、設定部１１７を介して第１通信処理部１１２から完了通知を受ける（ステップ１４ｆ）。

第２通信処理部１１５は、認可部１１８に対して、サーバ証明書発行のユーザ認可を求める許諾要求を送る（ステップ１５）。このとき、後段のステップ１７での表示用に、ユーザ情報（ｕｓｅｒ＿ｉｄ）を渡してもよい。第２通信処理部１１５は、一定期間、認可部１１８からの応答を待機する。応答が得られない場合または、ユーザからの拒否応答を受信した場合には、認可部１１８は、Ｗｅｂブラウザに対してエラー応答を行う。

第２通信処理部１１５は、認可部１１８からの応答を待っている間、受信したチャレンジコード（ｃｏｄｅ）に事前共有鍵で署名し、署名コード（ｓｉｇｎ）を生成する（ステップ１６）。署名コードは、チャレンジコードを事前共有鍵で暗号化した署名データに相当する。このとき、使用する署名のアルゴリズムは、署名アルゴリズムリストの中から任意に選択してもよい。ここでは、署名の処理を、認可部１１８からの応答を待っている間に実行しているが、証明書発行要求を受信してから、サーバ証明書の発行の認可を得るまでの間であれば、いつでも良い。

認可部１１８は、許諾要求を受けると、所定の方法でユーザに対し、サーバ証明書発行の認可を求める。ここでは、一例として、テレビの画面に、パスコードであるＰＩＮコード（４桁の数字等）を、証明書発行の認可を求める文言と共に表示する。これにより、ユーザに対し、テレビリモコンによるＰＩＮコードの入力を求める。

これは一例にすぎず、パスコードを表示せず、特定キー（決定ボタン等）の押下を求めるポップアップ表示を、機器１００の画面（テレビ画面）に表示する方法でもよい。または、テレビ自体がカメラまたは指紋読み取り装置などバイオメトリクス認証器を備え、これを用いてユーザに認可させる方法であってもよい。または、テレビがユーザパスワードの設定機能を備え、ユーザが、ユーザパスワードを再入力することによって、ユーザに認可させる方法であってもよい。

ユーザは、サーバ証明書の発行を認可する場合、パスコードを入力する（ステップ１８）。認可部１１８は、テレビ画面に表示したものと同じパスコードを受信すると、ユーザがサーバ証明書を認可したと判断する。認可部１１８は、ユーザが認可したことを示す許可情報を、第２通信処理部１１５に通知する（ステップ１５ｆ）。タイムアウト時間内にユーザの認可情報が得られない場合、またはパスコードの値が一定回数誤った場合は、認可部１１８は、エラー応答を返してもよい。この場合、第２通信処理部１１５は、発行済みのサーバ証明書を削除してもよい。または発行済みのサーバ証明書を第１通信処理部１１２で使用しないように制御してもよい。つまり、ユーザの認可情報が得られた場合のみ、証明書が発行または用いられるよう制御する。ユーザの認可情報を経てから、サーバ証明書を発行するようにステップの順序を変更することも可能である。

第２通信処理部１１５は、Ｗｅｂブラウザに対して、サーバ証明書（ｃｅｒｔ）、署名コード（ｓｉｇｎ）と、選択した署名アルゴリズムの識別情報とを含む応答を送信する（ステップ１１ｆ）。Ｗｅｂブラウザは、当該応答を、Ｗｅｂサーバ３０１のフロントエンドにフォワードする（ステップ１０ｆ）。なお、署名アルゴリズムの選択が行われなかった場合は、ステップ１１ｆ、ステップ１０ｆでの当該署名アルゴリズムの識別情報の送信は不要である。

応答を受信したフロントエンドは、バックエンドに、署名コード（ｓｉｇｎ）を含む署名確認要求を送信する（ステップ１９）。

バックエンドは、当該署名確認要求を、機器登録サーバ４０１にフォワードする（ステップ２０）。これにより、バックエンドは、機器登録サーバ４０１に対して、署名コード（ｓｉｇｎ）の検証を要求する。

機器登録サーバ４０１は、通信装置１０１との事前共有鍵を用いて、署名コード（ｓｉｇｎ）を検証する。機器登録サーバ４０１は、この署名コード（ｓｉｇｎ）が、チャレンジコード（ｃｏｄｅ）に事前共有鍵で署名したものであることを確認できた場合には、成功応答をバックエンドに送信する（ステップ２０ｆ）。バックエンドは、検証成功をフロントエンドに通知する（ステップ１９ｆ）。

フロントエンドは、検証成功の通知を受けると、第１ネットワーク５０１を介して、通信装置１０１の第１通信処理部１１２との間で、セキュアな通信により、アクセス確認を行う（ステップ２２）。典型的には、使用するプロトコル（ここではＨＴＴＰＳ）での導通確認である。ただし、第１通信処理部１１２の説明でも述べた通り、使用するプロトコルは、他のプロトコル（ＣＯＡＰＳ等）でも構わない。

なお、このときのアクセス先の情報は、サーバ証明書（ｃｅｒｔ）に含まれる第１通信処理部１１２の識別情報（ＩＰアドレス等）を用いてもよい。または、前述したステップ１１ｆ（Ｗｅｂブラウザからの証明書発行要求への応答）として、アクセス先の情報を、Ｗｅｂブラウザを介してフロントエンドに渡すようにし、この情報を用いてアクセス確認を行ってもよい。

本実施形態においては、ローカルＩＰアドレス（１９２．１６８．１１．２）に対するサーバ証明書（ｃｅｒｔ）が発行され、サーバ証明書（ｃｅｒｔ）の発行対象属性に設定されたこのアドレス（１９２．１６８．１１．２）に基づき、フロントエンドは、ｈｔｔｐｓ：／／１９２．１６８．１１．２／．ｗｅｌｌ＿ｋｎｏｗｎへのアクセス確認を行うものとする。なお、”．ｗｅｌｌ＿ｋｎｏｗｎ”は、ローカルサーバ（第１通信処理部）の属性情報を応答するエンドポイントであり、”．ｗｅｌｌ＿ｋｎｏｗｎ”である必要はない。ｉｎｄｅｘ．ｈｔｍｌであってもよく、形態は問わない。なお、“ｈｔｔｐｓ”（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルによって提供されるセキュアな接続の上でＨＴＴＰ通信を行うためのプロトコルである。

フロントエンドは、第１通信処理部１１２へのアクセスに失敗した場合には、第２通信処理部１１５を介して、第１通信処理部１１２に設定したサーバ証明書を削除するように構成してもよい。この導通確認処理は、フロントエンド側が実行したが、Ｗｅｂブラウザ側にＪａｖａＳｃｒｉｐｔ ＡＰＩを設けて、フロントエンドが、このＡＰＩを介して、Ｗｅｂブラウザに実行させるようにしてもよい。

フロントエンドは、第１通信処理部１１２へのアクセスに成功すると（ステップ２２ｆ）、当該サーバ証明書を、Ｗｅｂブラウザに、Ｗｅｂブラウザの信頼できるサーバ証明書として登録（保存）する（ステップ２３、２３ｆ）。サーバ証明書の具体的な保存方法の一例として、Ｗｅｂブラウザに証明書登録用のＪａｖａＳｃｒｉｐｔ ＡＰＩを設け、フロントエンドがこのＡＰＩを呼び出して、証明書登録を行うようにしてもよい。または、フロントエンドが、Ｗｅｂブラウザにユーザに保存認可を求めるポップアップを表示し、ユーザが認可ボタンを押下すると、サーバ証明書を直接保存するようにしてもよい。

ユーザが、Ｗｅｂブラウザを介して、Ｗｅｂサーバ３０１のフロントエンドへ、機器１００のリソースへのアクセスを要求する命令を送信する（ステップ２４）。リソースは、ここでは通信装置１０１は、テレビのリモコン機能である。一例として、チャンネル変更、電源オン・オフ、または録画予約などである。フロントエンドは、Ｗｅｂブラウザからリモコン操作の情報を受けると、第１ネットワーク５０１を介して、第１通信処理部１１２とＨＴＴＰＳ通信を行い、リソースへのアクセス要求（リモコン操作の指示情報）を送信する。

より詳細には、フロントエンドは、ＨＴＴＰＳ通信において第１通信処理部１１２とのＴＬＳハンドシェイク時に、サーバ証明書の検証を行う。Ｗｅｂブラウザに設定されたサーバ証明書と、第１通信処理部１１２に設定されたサーバ証明書が一致する場合は、フロントエンド（より詳細には、フロントエンドと接続しているＷｅｂブラウザ）は、機器１００を信頼できるものと判断し、以降、第１通信処理部１１２とＷｅｂブラウザとの間で、安全な暗号化通信が実現される。

Ｗｅｂサーバ３０１のオリジン情報と、通信装置１０１の第１通信処理部１１２のオリジン情報は異なっていることから、フロントエンドから第１通信処理部１１２へのアクセスは、クロスオリジンアクセス（異なるオリジン間でのアクセス）となる。Ｗｅｂサーバ３０１のオリジン情報は、第１通信処理部１１２のホワイトリストに登録されているため、第１通信処理部１１２は、異なるオリジン情報からのアクセス（クロスオリジン）を許容する。

第１通信処理部１１２は、安全な暗号化通信の下で、リソースへのアクセス要求（リモコン操作の情報）の命令を受信すると、当該命令に従って、チャネル変更等のリモコン機能を実行する。

図３は、本実施形態に係る通信装置１０１の動作のフローチャートである。第２通信処理部１１５が、第２通信部１１４を介して、チャレンジコード（署名対象データ）を含む証明書発行要求を受信する（ステップＡ１０１）。証明書発行要求は、一例として発行要求の第１形態に対応する。

第２通信処理部１１５は、秘密鍵と公開鍵のペアを生成し、第１通信処理部１１２の識別情報と、公開鍵および秘密鍵を用いて、第１通信処理部１１２の識別情報と公開鍵とを含み、秘密鍵により署名されたサーバ証明書を発行する（ステップＡ１０２）。このサーバ証明書は、一例として第１証明書に対応する。公開鍵および秘密鍵は、一例として、第１鍵および第１鍵と対になる第２鍵に相当する。署名は、例えば当該識別情報と公開鍵とを含むデータまたはそのハッシュ値を、秘密鍵により暗号化して署名データを生成することで行う。サーバ証明書は、当該データと署名データとを含むものとして構成される。

第２通信処理部１１５は、チャレンジコードを事前共有鍵で署名することにより署名コード（署名データ）を生成する（ステップＡ１０３）。一例として、通信装置１０１で保持される事前共有鍵は第３鍵、機器登録サーバ４０１で保持される事前共有鍵は第７鍵に相当する。第２通信処理部１１５は、サーバ証明書と秘密鍵とを、第１通信処理部１１２に設定する。

第２通信処理部１１５は、署名コードと、サーバ証明書とを、第２通信部１１４を介して送信する（ステップＡ１０４）。署名コードは、操作端末２０１およびＷｅｂサーバ３０１を介して、機器登録サーバ４０１に送信される。機器登録サーバ４０１では署名コードが検証され、検証に成功した場合は、成功の通知を、Ｗｅｂサーバ３０１に送信する。サーバ証明書は、Ｗｅｂサーバ３０１に操作端末を介して送信され、成功の通知を受けると、Ｗｅｂサーバ３０１は、サーバ証明書を、信頼できるサーバ証明書として、Ｗｅｂブラウザに保存する。

第１通信処理部１１２は、第１通信部１１１を介して、リモコン操作等のリソースへのアクセス（第１処理）を要求する命令を受信した場合に、サーバ証明書を当該命令の送信元との認証処理に用いる（ステップＡ１０５）。送信元（Ｗｅｂブラウザ）は、第１通信処理部１１２が、信頼できる証明書であることの検証に成功した場合にのみ、当該命令の送信元と通信を行うことで、リソースへのアクセス（リモコン操作等の動作）を行う（同ステップＡ１０５）。

以上、本実施形態によれば、Ｗｅｂサーバ３０１から、第１ネットワーク５０１（ローカルネットワーク等）上の機器１００に、安全にクロスオリジンアクセスできる。具体的には、機器１００による事前共有鍵の保持は、事前に機器登録サービスによって保証されており、この保証と、機器１００の所有者であるユーザの許諾とに基づいて、ＷｅｂサーバおよびＷｅｂブラウザは、機器１００の発行したサーバ証明書を信頼できるものと判断している。一方、ユーザは、すでにＷｅｂサービスのアカウントを保持しており、Ｗｅｂサービスを信頼している関係にあり、この前提のもとで、Ｗｅｂサーバから機器１００へのアクセスを、明確な意思表示に基づいて認めている。機器１００自体が、Ｗｅｂサーバ（および機器登録サーバ）を直接認証できていないことを除けば、ユーザを介在させた相互認証に基づく、ＨＴＴＰＳのクロスオリジンアクセスが実現できている。

＜第２実施形態＞
第１実施形態では、サーバ証明書として通信装置が自己署名証明書を発行したが、本実施形態では証明書署名要求（Ｃｅｒｔｉｆｉｃａｔｅ Ｓｉｇｎｉｎｇ Ｒｅｑｕｅｓｔ： ＣＳＲ）を発行し、証明書署名要求を認証局が署名することで証明書を発行する形態を示す。また、第１実施形態では第１通信処理部１１２のＩＰアドレスに対してサーバ証明書を発行したが、本実施形態では、第１通信処理部１１２に設定したローカルのドメイン名に対してサーバ証明書を発行する。

本実施形態のシステム構成図は図１と同じであるが、一部の要素の機能が拡張または変更されている。以下、第１実施形態との差分を中心に説明する。

通信装置１０１は、第１実施形態との差分として、サーバ証明書ではなく、証明書署名要求（ＣＳＲ）を発行する。

通信装置１０１の第１通信部１１１は、第１ネットワーク（ローカルネットワーク）５０１におけるドメイン名（ローカルドメイン名）の設定機能を備える。例えば第１通信部１１１は、ｍＤＮＳ（Ｍｕｌｔｉｃａｓｔ Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）クライアントの機能を備える。

第１記憶部１１３は、第１実施形態と同様、第１通信部１１１および第１通信処理部１１２に関わる設定を記憶する機能であり、本実施形態では、第１実施形態との差分として、ドメイン関連の設定情報を記憶している。設定情報の例として、ｍＤＮＳクライアントの設定ファイル（ドメイン名やＩＰアドレス等を含む）などを記憶している。

機器登録サーバ４０１は、第１実施形態との差分として、認証局の機能、すなわち、ＣＳＲに基づきサーバ証明書を発行する機能を備える。一例として、機器登録サーバ４０１は、ＣＳＲを秘密鍵で署名することで、サーバ証明書を発行する。この秘密鍵は、機器登録サーバ（この場合、正規認証局）のサーバ証明書（公開鍵）で検証可能な秘密鍵である。この秘密鍵は、一例として第４鍵に対応する。

図４に、第２実施形態に係るシステムの通信シーケンスを示す。図４のシーケンスの開始前には、第１実施形態における図２のステップ１からステップ８ｆまで（チャレンジコードの発行まで）行われるが、これらの図示は省略されている。また、図４のシーケンスの後には、図２のステップ２４〜ステップ２４ｆ（リソースへのアクセス）が行われるが、これらの図示も省略されている。

図４に示すように、Ｗｅｂサーバ３０１のフロントエンドは、Ｗｅｂブラウザに対して、証明書の発行要求ではなく、ＣＳＲ（証明書署名要求）発行要求を送信する（ステップ１）。ＣＳＲ発行要求は、チャレンジコード（ｃｏｄｅ）、オリジン情報（ｏｒｉｇｉｎ）およびユーザ情報（ｕｓｅｒ＿ｉｄ）を含む。

Ｗｅｂブラウザは、第２通信処理部１１５に対して、ＣＳＲ発行要求をフォワードする（ステップ２）。

第２通信処理部１１５は、図２のステップ１２と同様にして、鍵ペア（公開鍵および秘密鍵）を生成する（ステップ３）。

第２通信処理部１１５は、第１ネットワーク５０１のみで有効、かつ、ローカルＩＰアドレスが変化しても追従可能なローカルドメイン名（ｌｏｃａｌｄｏｍａｉｎ）を生成する（ステップ４）。例えば、Ｗｅｂサービスのドメイン名（ｔｖｃｏｎｔｒｏｌ．ｃｏｍ）を用いて、ｔｖｃｏｎｔｒｏｌ．ｃｏｍ．ｌｏｃａｌとしてローカルドメイン名を生成してもよい。あるいは、さらにユーザ情報（ｕｓｅｒ＿ｉｄ）がユーザのアカウント名の場合、アカウント名がａｌｉｃｅであれば、ａｌｉｃｅ．ｔｖｃｏｎｔｒｏｌ．ｃｏｍ．ｌｏｃａｌとして、ローカルドメイン名を生成してもよい。あるいは、通信装置１０１内で一意性が保証された鍵ＩＤ（ｋｅｙ＿ｉｄ）を用いて、ｋｅｙ＿ｉｄ．ｌｏｃａｌとして、ローカルドメイン名を生成してもよい。このように、様々なバリエーションが考えられる。ローカルドメイン名は、第１通信処理部１１２の識別情報の一例に相当する。

設定部１１７は、第１通信部１１１を介して、第２通信処理部１１５で生成された名前のローカルドメインを有効化する（ステップ５）。具体的には、設定部１１７が、第１記憶部１１３のｍＤＮＳ設定ファイルに、生成したローカルドメイン名（ｌｏｃａｌｄｏｍａｉｎ）を書き込み、第１通信部１１１のｍＤＮＳクライアントに、当該設定を読み込ませる。ｍＤＮＳクライアントは、当該設定を、ｍＤＮＳを用いて第１ネットワーク５０１内に登録する。以上が、典型的な実現形態として考えられるが、これに限定されるものではない。ローカルドメインの設定が完了すると、第１通信部１１１は、設定部１１７を介して、第２通信処理部１１５に、ローカルドメインの設定完了通知を送信する（ステップ５ｆ）。

設定部１１７は、さらに、第２通信処理部１１５からの指示を受けて、第１通信処理部１１２へオリジン情報の設定、より詳細には、ＣＯＲＳ（特定のオリジンからのアクセス認可）の設定を行う（ステップ６、ステップ６ｆ）。第１実施形態との差分として、この段階ではまだサーバ証明書が作成されていないため、サーバ証明書の設定は行わない。なお、もし第１通信処理部１１２のサーバ機能が起動されていない状態であれば、設定部１１７は、第１通信処理部１１２に起動処理を要求することで、サーバ機能を起動するよう制御する。

第２通信処理部１１５は、鍵ペア（公開鍵および秘密鍵）と、ローカルドメイン名（ｌｏｃａｌｄｏｍａｉｎ）とを用いて、必要に応じてさらにオリジン情報（ｏｒｉｇｉｎ）とユーザ情報（ｕｓｅｒ＿ｉｄ）を用いて、ＣＳＲ（証明書署名要求）を生成する（ステップ７）。図では、生成されたＣＳＲのデータを、ｃｓｒによって表している。ＣＳＲは、一例として、公開鍵と、ローカルドメイン名を含む。さらに、オリジン情報とユーザ情報の少なくとも一方を含んでもよい。

例えば、本実施形態ではサーバ証明書の発行は通信装置１０１ではなく、機器登録サーバ４０１が行うため、ＣＳＲに発行対象属性として、オリジン情報（ｏｒｉｇｉｎ）およびユーザ情報（ｕｓｅｒ＿ｉｄ）のいずれか、もしくは、両方を含めても良い。あるいは、これらに加え、またはこれらの代わりに、乱数、連番、またはランダム文字列を含めてもよい。

Ｘ．５０９を例にすると、発行対象属性（Ｓｕｂｊｅｃｔ）のサブ項目である組織 （Ｏ＝）に、機器１００（または通信装置１０１）の製造業者名、もしくは、Ｗｅｂサービス名（オリジン情報、またはオリジン情報に含まれるホスト名）を設定し、同じくサブ項目である発行対象名（ＣＮ＝）に、ローカルドメイン名（ｌｏｃａｌｄｏｍａｉｎ）を設定し、同じくサブ項目であるｅｍａｉｌアドレス（Ｅｍａｉｌ＝）に、ユーザ情報（ｕｓｅｒ＿ｉｄ）（例えばＷｅｂサービスへ登録したメールアドレス）を設定する。

第１実施形態のステップ１５と同様、第２通信処理部１１５は、認可部１１８に対して、サーバ証明書（またはＣＳＲ）の発行に関するユーザ認可を求める許諾要求を送る（ステップ８）。

第１実施形態のステップ１６と同様、第２通信処理部１１５は、認可部１１８からの応答を待っている間、受信したチャレンジコード（ｃｏｄｅ）に事前共有鍵で署名することにより、署名コード（ｓｉｇｎ）を生成する（ステップ９）。

認可部１１８は、許諾要求を受けて、機器１００の表示部に、ユーザの認可を求める認可ダイアログを表示する（ステップ１０）。認可ダイアログの例を図５に示す。図５の例では、「ＴＶリモコンサービスがアクセスを求めています。このアクセスには、ＴＶの証明書発行をともないます。発行しますか？［はい］［いいえ］」のダイアログが表示されている。第１実施形態でも、同様の認可ダイアログを表示してもよい。

ユーザが、テレビのリモコンを用いて、「はい」を選択し、決定ボタン１５１を押すと、認可部１１８は、その旨の信号を受信し、これによりユーザからの許諾が得られたと判断する（ステップ１１）。認可部１１８は、ユーザ許諾が得られたことを示す情報を第２通信処理部１１５に通知する（ステップ８ｆ）。第２通信処理部１１５は、生成した証明書署名要求（ｃｓｒ）、および署名コード（ｓｉｇｎ）を、ステップ２のＣＳＲ発行要求に対する応答として、Ｗｅｂブラウザに送信する（ステップ２ｆ）。タイムアウト時間内にユーザ認可が得られない場合等は、認可部１１８は、エラー応答を返してもよい。この場合、第２通信処理部１１５は、発行済みの証明書署名要求を削除してもよい。または発行済みの証明書証明要求をＷｅｂブラウザに送信しないように制御してもよい。つまり、ユーザの認可が得られた場合のみ、サーバ証明書が発行または用いられるよう制御する。なお、ユーザ認可を経てから、証明書署名要求を発行するように、ステップの順序を変更することも可能である。

Ｗｅｂブラウザは、証明書署名要求（ｃｓｒ）に含まれるドメイン名（ｌｏｃａｌｄｏｍａｉｎ）（ＣＮ＝）に対し、第１ネットワーク５０１を介して、アクセス確認（導通確認）を行う（ステップ１２、ステップ１２ｆ）。Ｗｅｂブラウザは、ドメイン名（ｌｏｃａｌｄｏｍａｉｎ）の存在が確認できた場合には、フロントエンド側に、ＣＳＲ発行要求（ステップ１）への成功応答として、証明書署名要求（ｃｓｒ）および署名コード（ｓｉｇｎ）を送信する（ステップ１ｆ）。アクセス確認の方法は、ここではＷｅｂブラウザ内部処理として実行したが、第１実施形態におけるステップ２２と同様に、フロントエンドで行ってもよい。

フロントエンドは、バックエンドに、署名コード（ｓｉｇｎ）と、証明書署名要求（ｃｓｒ）を送信する（ステップ１３）。これにより、署名コードの署名検証と、サーバ証明書の発行とを要求する。

バックエンドは、機器登録サーバ４０１に対して、署名コード（ｓｉｇｎ）の署名検証と、証明書署名要求（ｃｓｒ）への署名（すなわちサーバ証明書の発行）との要求を送信する（ステップ１４）。

機器登録サーバ４０１は、事前共有鍵を用いて、署名コード（ｓｉｇｎ）の署名を検証する（ステップ１５）。

機器登録サーバ４０１は、署名コード（ｓｉｇｎ）が、チャレンジコード（ｃｏｄｅ）に事前共有鍵で署名して得られるデータに一致することを確認できた場合は、すなわち、署名検証が成功した場合は、秘密鍵を用いて証明書署名要求（ｃｓｒ）へ署名する（ステップ１６）。これにより、サーバ証明書（ｃｅｒｔ）が発行される。この秘密鍵は、機器登録サーバ（この場合、正規認証局）のサーバ証明書（公開鍵）で検証可能な秘密鍵である。この秘密鍵は、一例として第４鍵に対応する。このサーバ証明書は、一例として、証明書署名要求の内容（ローカルドメイン名、公開鍵等）と、当該秘密鍵により当該証明書署名要求（または証明書署名要求のハッシュ値）を署名したデータ（署名）とを含む。

フロントエンドは、機器登録サーバ４０１から、バックエンドを介して、サーバ証明書（ｃｅｒｔ）を受け取る（ステップ１４ｆ、ステップ１３ｆ）。フロントエンドは、Ｗｅｂブラウザに設けられたサーバ証明書登録ＡＰＩに対し、サーバ証明書の登録要求（保存要求）を送信する（ステップ１７）。この登録要求は、サーバ証明書を含む。

Ｗｅｂブラウザは、第２ネットワーク６０１を介して登録要求を受信し、第２通信処理部１１５に対して、この登録要求をフォワードする（ステップ１８）。

第２通信処理部１１５は、設定部１１７に対して、サーバ証明書（ｃｅｒｔ）と、これに対応する秘密鍵（ｓｅｃｒｅｔ）とを第１通信処理部１１２に設定することを指示する（ステップ１９）。設定部１１７は、第１通信処理部１１２に、サーバ証明書（ｃｅｒｔ）と秘密鍵（ｓｅｃｒｅｔ）とを設定する。

より具体的には、設定部１１７は、第２記憶部１１６内または第２通信処理部１１５のワークメモリ内にキャッシュされた秘密鍵（ｓｅｃｒｅｔ）を取得し、第１記憶部１１３内の所定のディレクトリに、秘密鍵を保存する。また設定部１１７は、サーバ証明書も第１記憶部１１３に保存する。そして、設定部１１７は、第１通信処理部１１２のサーバ機能を再起動するか、あるいは、サーバ機能に、サーバ証明書および秘密鍵を再読込させるよう制御する。

Ｗｅｂブラウザは、第２通信処理部１１５からの成功応答（ステップ１８ｆ）を受けて、サーバ証明書を信頼できるサーバ証明書として操作端末２０１内の記憶領域に保存する（ステップ２０）。そして、Ｗｅｂブラウザは、フロントエンドにサーバ証明書の登録が完了した旨の応答を送信する（ステップ１７ｆ）。

以上の手順により、正規認証局（機器登録サーバ４０１）により署名され、かつ、通信装置１０１のＩＰアドレス変化にも追従可能な、正規のサーバ証明書を発行することができる。なお、本実施形態における第１通信処理部１１２は、Ｗｅｂサーバ（アクセス元）のオリジンに応じた異なるドメイン名を複数付与され得る。設定部１１７は、第１通信処理部１１２に、１つのドメインないし固定数のドメインしか付与されないように制限をかけてもよい。複数のドメイン名の付与を許容する場合、第１通信処理部１１２は、ＳＮＩ（Ｓｅｒｖｅｒ Ｎａｍｅ Ｉｎｄｉｃａｔｉｏｎ）に基づき、アクセスされたドメイン名に応じて、サーバ証明書を使い分ける機構を備える。

図６は、本実施形態に係る通信装置１０１の動作のフローチャートである。第２通信処理部１１５が、第２通信部１１４を介して、チャレンジコード（署名対象データ）を含むＣＳＲ発行要求を受信する（ステップＡ１１１）。ＣＳＲ発行要求は、一例として発行要求の第２形態に対応する。

第２通信処理部１１５は、秘密鍵および公開鍵を生成し、第１通信処理部１１２の識別情報および公開鍵等を用いて、第１通信処理部１１２の識別情報と公開鍵とを含むＣＳＲ（証明書署名要求）を生成する（ステップＡ１１２）。

第２通信処理部１１５は、チャレンジコードを事前共有鍵で署名することにより署名コード（署名データ）を生成する（ステップＡ１１３）。一例として、通信装置１０１で保持される事前共有鍵は第３鍵、機器登録サーバ４０１で保持される事前共有鍵は第７鍵に相当する。

第２通信処理部１１５は、署名コードと、ＣＳＲとを、第２通信部１１４を介して送信する（ステップＡ１１４）。署名コードおよびＣＳＲは、操作端末２０１およびＷｅｂサーバ３０１を介して、機器登録サーバ４０１に送信される。機器登録サーバ４０１では署名コードが検証され、検証に成功した場合は、秘密鍵で証明書署名要求に署名することでサーバ証明書を発行する。このサーバ証明書は、一例として第２証明書に対応する。サーバ証明書を、Ｗｅｂサーバ３０１に送信する。Ｗｅｂサーバ３０１は、サーバ証明書を、信頼できるサーバ証明書として、Ｗｅｂブラウザに保存する。また、Ｗｅｂサーバ３０１は、操作端末２０１を介してサーバ証明書を第２通信処理部１１５に送る。第２通信処理部１１５は、サーバ証明書を受信し（ステップＡ１１５）、サーバ証明書と秘密鍵とを、第１通信処理部１１２に設定する。

第１通信処理部１１２は、第１通信部１１１を介して、リモコン操作等のリソースへのアクセス（第１処理）を要求する命令を受信した場合に、サーバ証明書を用いて当該命令の送信元と認証処理を行う（ステップＡ１１６）。例えば第１通信処理部１１２がサーバ証明書をＷｅｂブラウザまたはＷｅｂサーバ３０１に送信し、ＷｅｂブラウザまたはＷｅｂサーバ３０１に保存されている証明書と、第１通信処理部１１２が送ったサーバ証明書が一致する場合に、認証処理が成功する。第１通信処理部１１２は、認証処理に成功した場合に、秘密鍵を用いて当該命令の送信元と通信を行って、リソースへのアクセスを行う（同ステップＡ１１６）。

以上、本実施形態によれば、通信装置１０１で証明書署名要求（ＣＳＲ）を発行し、このＣＳＲを認証局で署名することで、サーバ証明書を作成するため、認証局による検証を経て、サーバ証明書を発行することができる。第１実施形態では、発行するサーバ証明書が、通信装置１０１自身で発行する自己署名証明書であったため、認証局の検証が行われていないものであったが、本実施形態では、認証局の認証を経たサーバ証明書を実現できる。

また、本実施形態では、第１通信処理部１１２に設定したローカルドメイン名に対してサーバ証明書を発行するため、第１通信処理部１１２のローカルＩＰアドレスが変化しても、サーバ証明書を継続して使用できる。

＜第３実施形態＞
第１および第２実施形態では、通信装置１０１が、サーバ証明書の発行に関するユーザの認可意思の確認を行うための物理インタフェース（テレビの画面およびリモコン等）を備える機器に搭載されていたが、本実施形態では、通信装置１０１が、そのような物理インタフェースが搭載されていない場合の形態を示す。

図７に、第３実施形態に係る通信装置１０１を備えたシステムの全体構成を示す。第１および第２実施形態と異なり、通信装置１０１が、上記物理インタフェースを持たない機器、具体的には、ホームゲートウェイ装置１５０に搭載されている。ホームゲートウェイ装置１５０は、宅内家電機器の監視・制御機能をブロードバンドルータに搭載したものである。

特に本実施形態では、ホームゲートウェイ装置１５０は、ＨＥＭＳ（Ｈｏｍｅ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）関連の標準通信プロトコルであるＥＣＨＯＮＥＴに準拠し、第１ネットワーク５０１（ホームネットワーク等）からＥＣＨＯＮＥＴ対応の監視・制御ができるようにプロトコル変換を担うゲートウェイ装置であるとする。

以下、第１および第２実施形態とのシステム構成上の差分を中心に説明する。

ゲートウェイ装置１５０（より詳細には通信装置１０１）は、第４ネットワーク８０１を介して、１つまたは複数の機器に接続されている。具体的に、第４ネットワーク８０１は、ＥＣＨＯＮＥＴまたはＳＥＰ２．０準拠のネットワークである。第４ネットワーク８０１は、ＢｌｕｅｔｏｏｔｈまたはＺｉｇｂｅｅなど、他のプロトコルに準拠したネットワークでもよい。また第４ネットワーク８０１は、第１ネットワーク５０１または第２ネットワーク６０１と、物理的には同じものであってもよい。

第４ネットワーク８０１に接続された機器は、ゲートウェイ装置１５０経由で監視・制御される機器である。本実施形態では、第４ネットワーク８０１上の機器は、ＥＣＨＯＮＥＴ対応機器であるとする。本実施形態では、第４ネットワーク８０１上の機器のうちの１つは、スマートメータであるとする。

通信装置１０１は、第１実施形態または第２実施形態の通信装置が備えるブロックに加え、第４通信部１２３および第４通信処理部１２４を備え、認可部１１８等の機能が拡張または変更されている。

第４通信部１２３は、制御対象である第４ネットワーク８０１上の機器との通信を行う。物理媒体は、第１通信部１１１および第２通信部１１４と共通であってもよい。ここでは、第４通信部１２３は、物理媒体の上位層のプロトコル、具体的にはＭＡＣ層からＥＣＨＯＮＥＴプロトコルまでを含む通信モジュール機能を備えているとする。第４通信部１２３は、一例として通信回路によって構成される。通信回路は、ハードウェアのみによって構成されてもよいし、ハードウェアとソフトウェアによって構成されてもよい。

第４通信処理部１２４は、第１ネットワーク５０１上の操作端末２０１と、第４ネットワーク８０１上の機器間で、プロトコル変換を行う。本実施形態では、第４通信処理部１２４は、ＨＴＴＰとＥＣＨＯＮＥＴ間のプロトコル変換を行う。

認可部１１８は、操作端末２０１から第１通信処理部１１２を介してユーザ認可要求（以下、認可要求と呼ぶ）を受信し、ユーザが認可（または拒絶）を行うための認可画面を操作端末２０１に表示させるよう制御する。認可部１１８は、ＣＡＰＴＣＨＡ（画面に表示した文字の画像データと同じ文字をユーザに入力させることで、機械による自動操作を防ぐ仕組み）などを用いて、ユーザ操作の介在を保証する仕組みを提供するものとする。ユーザは、認可画面で認可（あるいは拒絶）を行い、入力した情報が操作端末２０１に送られる。操作端末２０１は、ユーザの認可が得られた場合、その旨を認可部１１８に通知する。

認可部１１８は、第１通信処理部１１２経由で受信する認可要求と、ユーザが認可画面で行う認可とを紐付けるために、ユーザ認可が得られたセッションＩＤを第２通信処理部１１５に送信する。これにより第２通信処理部１１５は、セッションＩＤを介在させたユーザ認証を行うことができる。

図８に、第３実施形態に係るシステムの通信シーケンスを示す。本シーケンスでは、ユーザシナリオとして、ユーザが、操作端末２０１のＷｅｂブラウザで、クラウド型ＨＥＭＳサービスのＷｅｂ画面を表示し、第４ネットワーク８０１上の機器（ここではスマートメータ）の電力使用量の積算値を、ゲートウェイ装置１５０経由で取得する場合を想定する。

図８のシーケンスの開始前には、第１実施形態のシーケンス（図２）のステップ１からステップ８ｆまで（チャレンジコードの発行まで）行われるが、これらの図示は省略されている。また、図８のシーケンスの後には、第２実施形態のシーケンス（図４）のステップ１３以降の処理（署名検証および証明書発行に関する処理）が行われるが、これらの図示も省略されている。

図８のステップ１からステップ５ｆまでは、第２実施形態のシーケンス（図４）のステップ１からステップ５ｆと同じであるため、説明を省略する。

第２通信処理部１１５は、ユーザに認可画面を表示するための一時的な自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）を作成する（ステップ６）。その有効期限は、一例として、３０秒など、短く設定する。自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）の作成には、鍵ペア（ｐｕｂ，ｓｅｃｒｅｔ）、ローカルドメイン名（ｌｏｃａｌｄｏｍａｉｎ）、オリジン情報（ｏｒｉｇｉｎ）およびユーザ情報（ｕｓｅｒ＿ｉｎｆｏ）のうちの全部または一部を用いればよい。鍵ペアの公開鍵（ｐｕｂ）は第５鍵、秘密鍵（ｓｅｃｒｅｔ）は第６鍵に対応する。

第２通信処理部１１５は、後述する操作端末２０１からの認可画面へのアクセスと、ステップ１のＣＳＲ発行要求とを関連づけるためのセッションＩＤ（ｓｉｄ）を生成する（ステップ７）。

第２通信処理部１１５は、設定部１１７を介して、第１通信処理部１１２に、秘密鍵、自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）、セッションＩＤ（ｓｉｄ）およびオリジン情報を設定する（ステップ８、ステップ８ｆ）。

そして、第２通信処理部１１５は、認可処理のために、第１通信処理部１１２を一時的に起動し（一時的にオリジン情報（ｏｒｉｇｉｎ）からのアクセスを認可し）、自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）とセッションＩＤ（ｓｉｄ）を、Ｗｅｂブラウザに応答する（ステップ２ｆ）。この時、認可画面のＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）を併せて応答してもよい。または、認可画面の相対パスを予め固定の値に定義しておき、自己署名サーバ証明書に含まれるドメイン情報のみから、認可画面ＵＲＬをＷｅｂブラウザで導出できるようにしてもよい。この場合、第２通信処理部１１５は、認可画面のＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）を応答しなくてよい。

Ｗｅｂブラウザは、自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）を、信頼できる証明書として、操作端末２０１内のアクセス可能な領域に保存する（ステップ９）。

Ｗｅｂブラウザは、第１ネットワーク５０１を介して、第１通信処理部１１２（ＨＴＴＰＳサーバ）に、認可画面の要求を送信する（ステップ１０）。当該要求は、認可画面のＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）と、セッションＩＤ（ｓｉｄ）とを含む。許可画面の要求の送信前、Ｗｅｂブラウザは、自己署名サーバ証明書（ｔｍｐ＿ｃｅｒｔ）を用いて、第１通信処理部１１２と認証を行う。Ｗｅｂブラウザが保有している自己署名サーバ証明書が、第１通信処理部１１２で保持されている自己署名サーバ証明書と一致していれば（自己署名サーバ証明書が、信頼できるサーバ証明書として登録されていれば）、認証の成功を決定する。

第１通信処理部１１２は、セッションＩＤ（ｓｉｄ）をチェックする（ステップ１１）。

第１通信処理部１１２は、ステップ８で設定されたセッションＩＤと、受信したセッションＩＤが一致するときは、セッションＩＤ（ｓｉｄ）の認証が成功したと判断し、認可部１１８を介して、認可画面をＷｅｂブラウザに応答する（ステップ１２、ステップ１２ｆ、ステップ１０ｆ）。すなわち、第１通信処理部１１２は、認可部１１８に、セッションＩＤを含む認可要求を送信して（ステップ１２）、認可部１１８から応答として認可画面を受信し（ステップ１２ｆ）、当該認可画面を、Ｗｅｂブラウザに送信する（ステップ１０ｆ）。

Ｗｅｂブラウザは、認可画面のポップアップ表示の要求を、フロントエンドに送信する。この要求はセッションＩＤを含んでもよい（ステップ１３）。フロントエンドは、操作端末２０１のＷｅｂブラウザに、認可画面をポップアップ表示するよう制御する。

図９に、操作端末２０１のＷｅｂブラウザに表示される認可画面の例を示す。この画面には、「認可しますか［はい］［いいえ］」のダイアログが表示されている。この際、ＣＡＰＴＣＨＡ用の画像も併せて表示し、ユーザにこの画像に対応するコードを入力させることで、ユーザの介在を保証してもよい。

ユーザは、認可する場合、ＣＡＰＴＣＨＡ用の画像に対応するコードを入力し、［はい］ボタンを押下する（ステップ１４）。なお、図９ではＣＡＰＴＣＨＡ用の画像および入力フィールドの表示は省略されている。ユーザの介在を保証する手段として、ＣＡＰＴＣＨＡ以外の方法を用いてもよい。

フロントエンドまたはＷｅｂブラウザは、認可部１１８に、ユーザ認可を取得できたとの通知を送信する（ステップ１５）。この通知は、セッションＩＤを含んでもよい。認可部１１８は、第２通信処理部１１５に、セッションＩＤ（ｓｉｄ）に対応するユーザから、認可を取得できたとの通知を送信する（ステップ１６）。また、認可部１１８は、第２通信処理部１１５への通知の完了を、フロントエンドに応答する（ステップ１５ｆ）。

フロントエンドは、ユーザの認可処理の成功をＷｅｂブラウザに通知し（ステップ１３ｆ）、Ｗｅｂブラウザは、改めて、ＣＳＲ発行要求を、第２通信処理部１１５に送信する（ステップ１７）。このＣＳＲ発行要求は、セッションＩＤ（ｓｉｄ）を含む。

第２通信処理部１１５は、ＣＳＲ発行要求を受けると、事前に認可部１１８からユーザ認可が得られたとの通知を受けている場合は（ステップ１６参照）、証明書署名要求（ＣＳＲ）を生成する（ステップ１８）。証明書署名要求（ＣＳＲ）は、第２実施形態と同様のものでよい。

第２通信処理部１１５は、チャレンジコード（ｃｏｄｅ）に事前共有鍵で署名することにより、署名コード（ｓｉｇｎ）を生成する（ステップ１９）。

第２通信処理部１１５は、証明書署名要求（ｃｓｒ）と、署名コード（ｓｉｇｎ）とをＷｅｂブラウザに応答する（ステップ１７ｆ）。Ｗｅｂブラウザは、証明書署名要求（ｃｓｒ）と、署名コード（ｓｉｇｎ）とを、ステップ１のＣＳＲ発行要求に対する応答として、送信する（ステップ１ｆ）。これより後のステップは、前述した通り、第２実施形態における図４のステップ１３以降と同じである。

以上の手順により、通信装置１０１が、ユーザが認可意思を行うためのユーザインタフェースを持たない機器に搭載されている場合も、正規認証局（機器登録サーバ４０１）の署名が付与され、かつ、通信装置１０１のＩＰアドレス変化にも追従可能な、正規のサーバ証明書を発行できる。

上述した手順は、第２実施形態のシーケンス（ＣＳＲ発行要求を受信した場合のシーケンス）を前提としたが、第１実施形態のシーケンス（証明書発行要求を受信した場合のシーケンス）の場合でも、同様にして実施可能である。

本実施形態に係る通信装置１０１が搭載される機器は、ゲートウェイ装置以外にも様々な応用が考えられる。ゲートウェイ装置以外の機器の例として、Ｗｉ−Ｆｉ機能を搭載したＳＤカードが挙げられる。この場合、例えば、第１のネットワークおよび第１通信部１１１がＷｉ−Ｆｉに対応し、第２のネットワークおよび第２通信部１１４がＳＤＩＯに対応する。通信機能を持たないレガシー機器に、Ｗｉ−Ｆｉ機能付きＳＤカードを挿入することで、レガシー機器をＩｏＴ機器化する応用シナリオを説明する。図１０および図１１は、当該シナリオを説明するための図である。

図１０に示すように、ユーザが、本実施形態に係る通信装置１０１が搭載されたＳＤカードを、操作端末２０１に挿入する。通信機能を持たないレガシー機器１６０が、ユーザ宅内に配置されている。操作端末２０１は、例えばノートパソコン等のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）である。

ユーザが、ＳＤカードが挿入された操作端末２０１上のＷｅｂブラウザを操作して、ＳＤカード対応機器のＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）化サービスにログインする。ＩｏＴ化サービスは、Ｗｅｂサーバ３０１が提供するＷｅｂサービスに対応する。

本実施形態の通信シーケンス（図８）に基づき、ＳＤカードに対するサーバ証明書が生成され、ＳＤカードに保存される。このとき、ＳＤカードを介して制御する対象となる機器（レガシー機器１６０）を、第１通信処理部１１２（ＨＴＴＰサーバ）経由で制御するためのロジック（ＣＧＩ等）のデータも、ＳＤカードに設定する。このロジックは、ＨＴＴＰサーバ上で動くプログラムである。ロジックは、Ｗｅｂサーバ３０１から提供されてもよいし、操作端末２０１に事前にインストールされていてもよい。

この後、図１１に示すように、ユーザがＳＤカードを、操作端末２０１から抜き、レガシー機器１６０に挿入することで、レガシー機器１６０がＩｏＴ化される。すなわち、レガシー機器１６０が、第１ネットワーク５０１を介して制御可能になる。この後は、操作端末２０１のＷｅｂブラウザから、当該ＩｏＴ化された機器に、Ｗｅｂサーバ３０１を介して、クロスオリジンアクセスする。このときＣＯＲＳ設定によって、当該Ｗｅｂサーバ３０１のフロントエンドからのみアクセスを許可するように制御することも可能である。ＳＤカード内の第１通信処理部１１２のＨＴＴＰサーバで動くＣＧＩ等のロジックが、第２通信部１１４（ＳＤＩＯ）を介して、当該レガシー機器１６０の制御を行う。これにより、操作端末２０１から、ＩｏＴ化されたレガシー機器１６０を制御したり、当該レガシー機器１６０がＳＤカードに保存したデータを取得することができる。なお、上述のシナリオでは、第２通信部１１４として、ＳＤＩＯを想定したが、第１通信部１１１と同様、ＷｉＦｉであってもよい。具体的には、当該ＳＤカードのＷｉ−Ｆｉ機能が、アクセスポイント機能とステーション機能を双方備え、第２通信部１１４は、アクセスポイント機能側、第１通信部１１１は、ステーション機能側であってもよい。このとき設定部１１７が、証明書発行までは、アクセスポイント機能を動作させ、証明書発行後は、ステーションモード機能を動作させるように、Ｗｉ−Ｆｉの動作モードも制御するように構成してもよい。

＜第４実施形態＞
第１〜第３実施形態では、サーバ証明書を発行することでＷｅｂサービスが通信装置１０１または機器（またはゲートウェイ装置）の正当性を判定することを可能にしたが、本実施形態では、Ｗｅｂサービスに対してクライアント証明書を発行することで、機器側がＷｅｂサービスの妥当性を検証することを可能にする。端的には、機器側が、第１〜第３実施形態の機器登録サービスの役割に対応する機能を備えることで、Ｗｅｂサービスの妥当性を検証する。

本実施形態のシステム構成は、前述した第３実施形態に係る図７と同じである。但し、通信装置１０１の機能が一部変更または拡張されている。

第２通信処理部１１５は、第３実施形態との差分として、チャレンジコード（ｃｏｄｅ）発行機能、署名検証機能、およびクライアント証明書発行機能、を備える。

図１２に、第４実施形態に係るシステムの通信シーケンスを示す。ユーザシナリオは、第３実施形態と同様、ユーザが、操作端末２０１のＷｅｂブラウザで、クラウド型ＨＥＭＳサービスのＷｅｂ画面を表示し、第４ネットワーク８０１上の機器（ここではスマートメータ）の電力使用量の積算値を、ゲートウェイ装置（機器）１５０経由で取得する場合を想定する。

第２通信処理部１１５は、フロントエンドからＷｅｂブラウザを介して、通信装置１０１の第１通信処理部１１２（ＨＴＴＰサーバ）用のＣＳＲ発行要求を受信する（ステップ１）。第２通信処理部１１５は、当該ＣＳＲ発行要求の応答として、チャレンジコード（ｃｏｄｅ＿ｆｏｒ＿ｃｌｉｅｎｔ＿ｃｅｒｔ）を発行し、フロントエンドに送信する（ステップ１ｆ）。この際、第２通信処理部１１５は、ＣＳＲ発行要求の受信に応じて、図８のステップ２以降（サーバ証明書用のＣＳＲ発行処理）を行い、図１２のステップ１ｆの応答では、図８のステップ１ｆの応答を兼ねてもよい。この場合、以降の動作は、各応答に対して別々にシーケンスが行われてもよい。あるいは、図８のステップ１ｆの後の処理を先に行って、サーバ証明書の設定が完了してから、図１２のステップ１ｆより後の処理（チャレンジコードの応答以降のシーケンス）が開始されてもよい。

別の方法として、第２通信処理部１１５が、クライアント証明書発行用のチャレンジコード要求インタフェースを備えていてもよい。この場合には、第２通信処理部１１５が、フロントエンドからＷｅｂブラウザを介して、チャレンジコード発行要求を受信して、チャレンジコード（ｃｏｄｅ＿ｆｏｒ＿ｃｌｉｅｎｔ＿ｃｅｒｔ）を応答するように構成してもよい。

Ｗｅｂサービスのフロントエンドは、取得したチャレンジコード（ｃｏｄｅ＿ｆｏｒ＿ｃｌｉｅｎｔ＿ｃｅｒｔ）をバックエンドに送る（ステップ２）。

バックエンドは、このチャレンジコード（ｃｏｄｅ＿ｆｏｒ＿ｃｌｉｅｎｔ＿ｃｅｒｔ）を機器登録サーバ４０１に、ＣＳＲ発行要求の引数として送信する（ステップ３）。

機器登録サーバ４０１は、チャレンジコード（ｃｏｄｅ＿ｆｏｒ＿ｃｌｉｅｎｔ＿ｃｅｒｔ）に事前共有鍵で署名し（ステップ４）、署名されたチャレンジコードである署名コード（ｓｉｇｎｅｄ＿ｃｏｄｅ）を、バックエンドに応答する（ステップ３ｆ）。

バックエンドは、鍵ペア（秘密鍵および公開鍵）を生成する（ステップ５）。バックエンドは、秘密鍵を内部に保持し、また、Ｗｅｂサービスの識別情報および公開鍵等を含む証明書署名要求（ＣＳＲ）を生成する（同ステップ５）。バックエンドは、署名コード（ｓｉｇｎｅｄ＿ｃｏｄｅ）と、証明書署名要求（ＣＳＲ）とを、フロントエンドに応答する（ステップ２ｆ）。

フロントエンドは、Ｗｅｂブラウザに対して、署名コード（ｓｉｇｎｅｄ＿ｃｏｄｅ）と証明書署名要求とを引数として含むクライアント証明書発行要求を送信する（ステップ６）。

Ｗｅｂブラウザは、当該クライアント証明書発行要求を、第２通信処理部１１５にフォワードする（ステップ７）。

第２通信処理部１１５は、受信したクライアント証明書発行要求に含まれる署名コード（ｓｉｇｎｅｄ＿ｃｏｄｅ）を、事前共有鍵を用いて、検証する（ステップ８）。失敗した場合には、エラー応答を返す。

検証に成功した場合には、第２通信処理部１１５は、ユーザにクライアント証明書発行を求めるための認可処理を実行する（ステップ９）。この認可処理は、第１〜第３実施形態と同様であるため、詳細な説明を省略する。

第２通信処理部１１５は、サーバ証明書の秘密鍵を用いて、証明書署名要求（ＣＳＲ）に署名することで、クライアント証明書（ｃｌｉｅｎｔ＿ｃｅｒｔ）を発行する（ステップ１０）。第２通信処理部１１５は、クライアント証明書（ｃｌｉｅｎｔ＿ｃｅｒｔ）をＷｅｂブラウザに送信する（ステップ７ｆ）。ここで用いる秘密鍵は、クライアント証明書発行要求の要求元を表すオリジン情報（Ｗｅｂサービス）およびユーザに対応するサーバ証明書の秘密鍵である。

Ｗｅｂブラウザは、受信したクライアント証明書（ｃｌｉｅｎｔ＿ｃｅｒｔ）をフロントエンドにフォワードする（ステップ６ｆ）。

フロントエンドは、受信したクライアント証明書を含むクライアント証明書登録要求を生成し、バックエンドに送信する（ステップ１１）。

バックエンドは、受信したクライアント証明書と、ステップ５で作成して保存しておいた秘密鍵とを含むファイルを作成し（ステップ１２）、このファイルをフロントエンドに送信する（ステップ１１ｆ）。

フロントエンドは、受信したファイル（一般的には、ｐ１２ファイルと呼ばれるもの）を、Ｗｅｂブラウザに保存（インストール）する（ステップ１３）。この時、Ｗｅｂブラウザ画面にインストールダイアログを表示して、明示的にユーザに、ファイルのインストールを行わせるように構成してもよい。

フロントエンドが、Ｗｅｂブラウザを介してユーザからリソースアクセスの要求（監視または制御の要求）を受ける。フロントエンドが、第１通信処理部１１２に対し、ゲートウェイ装置１５０配下の機器の監視または制御の命令を、ＨＴＴＰＳプロトコルで発行して、送信する（ステップ１４）。この時、下位層のＴＬＳ接続確立時に、クライアント証明書およびサーバ証明書に基づく相互認証が行われる。クライアント証明書に基づく認証は、一例として、以下のように行えばよい。第１通信処理部１１２が、フロントエンドまたはＷｅｂブラウザから、クライアント証明書を受信する。受信したクライアント証明書の署名を、サーバ証明書の秘密鍵で復号し、復号したデータが、クライアント証明書の署名以外の本体部分（ＣＳＲに相当する部分）またはそのハッシュ値と一致すれば、そのクライアント証明書は信頼できると判断する。認証後の通信は、サーバ証明書の秘密鍵および公開鍵を用いて暗号化すればよいが、クライアント証明書の秘密鍵および公開鍵を用いて暗号化することも可能である。

第４通信処理部１２４は、当該命令をプロトコル変換し、ゲートウェイ装置配１５０下の機器に 換後の命令を送信する。これにより機器の監視・制御が実行される（ステップ１５、ステップ１５ｆ）。第１通信処理部１１２は、監視・制御の結果を、フロントエンドにフィードバックする（ステップ１４ｆ）。

以上の手順によって、通信装置１０１上のローカルサーバ（第１通信処理部１１２）が、アクセス元（Ｗｅｂサービスおよびユーザ）の検証を、クライアント証明書を用いて行うことができる。このとき、クライアント証明書は、ローカルサーバにアクセス可能なユーザによる認可のもとで、機器登録サーバ４０１から署名をもらうことができる関係にある（正規の）Ｗｅｂサービスに対して発行できている。

なお、サーバ証明書の発行とクライアント証明書の発行とを一連の処理として行う場合には、ユーザ認可をまとめて１回のみ行うようにしてもよい。一例として、サーバ証明書の生成時にユーザの認可がとれていれば、図１２のステップ９は省略してもよい。

＜第５実施形態＞
第４実施形態では、通信装置１０１が、クライアント証明書によってアクセス元（Ｗｅｂサービスおよびユーザ）の検証を行うことができるが、クライアント証明書のインストールおよび更新に手間がかかる。本実施形態では、通信装置１０１上の第１通信処理部１１２が行うアクセス元の認証を、Ｗｅｂサービスのユーザ認証に統合する（すなわち、通信装置１０１が、ユーザ認証をＷｅｂサービスに移譲する）ことで、この問題を解消する。

本実施形態のシステム構成は、前述した第３実施形態に係る図７と同じである。但し、通信装置１０１の機能が一部変更または拡張されている。

第１通信処理部１１２は、第１〜第３実施形態のＨＴＴＰサーバ機能に加えて、クライアント登録機能と、認可移譲機能と、トークン検証機能と、ユーザ情報取得機能とを備える。

図１３に、第５実施形態に係るシステムの通信シーケンスを示す。図１３には、第３実施形態におけるサーバ証明書の発行時点からのシーケンスが示される。これより前は、第３実施形態と同様のシーケンス（すなわち、図２のステップ１〜ステップ８と、これに続く図８のシーケンスと、さらにこれに続く図４のステップ１３〜ステップ１３ｆ）が行われる。ユーザシナリオは、第３実施形態と同様である。

前提として、Ｗｅｂサーバが、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ、およびＯＡｕｔｈ ２．０というＷｅｂ上でアクセス権限の移譲を行うプロトコルの認可サーバ機能を備えているものとする。

第２通信処理部１１５は、機器登録サーバ４０１の署名により生成されたサーバ証明書（ｃｅｒｔ）の登録要求を、Ｗｅｂブラウザを介して、受信する（ステップ１）。

この登録要求は、サーバ証明書を含み、さらにパラメータとして、Ｗｅｂサービスへのクライアント登録ＵＲＬ（ｒｅｇｉｓｔｅｒ＿ｕｒｌ）、認可画面ＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）の情報を含む。

クライアントとは、第１通信処理部１１２（ＨＴＴＰサーバ）のことである。つまり、第１通信処理部１１２が、Ｗｅｂサービスに認証を移譲するＲＰ （Ｒｅｌｙｉｎｇ Ｐａｒｔｙ）である。なお、バリエーションとして、こうした個別のＵＲＬではなく、Ｗｅｂサービス側のＵＲＬ情報を一覧したファイルへのパスでもよい。具体的な実現方法は問わない。

第２通信処理部１１５は、第１通信処理部１１２に、サーバ証明書を登録する（ステップ２）。

第２通信処理部１１５は、設定部１１７を介して、第１通信処理部１１２へ、Ｗｅｂサービスへのクライアント登録を指示するクライアント登録要求を送る（ステップ３）。クライアント登録要求は、クライアント登録ＵＲＬ（ｒｅｇｉｓｔｅｒ＿ｕｒｌ）を含む。クライアント登録ＵＲＬは、第１通信処理部１１２（ＨＴＴＰ）であるクライアントを、Ｗｅｂサーバ３０１に登録するために使用するＵＲＬである。このＵＲＬは、Ｗｅｂサーバ３０１が提供するＷｅｂサービス内のパスである。

第１通信処理部１１２のクライアント登録機能は、第１ネットワーク５０１を介して、Ｗｅｂサーバ３０１のバックエンドに対して、クライアント登録依頼を送信する（ステップ４）。このクライアント登録依頼は、少なくとも、後述するユーザによる認証完了後にリダイレクトバックする画面のパス（ｒｅｄｉｒｅｃｔ＿ｕｒｌ）を含む。なお、第１通信処理部１１２は、Ｗｅｂサーバ３０１と直接通信する代わりに、第２通信処理部１１５およびＷｅｂブラウザを介して、Ｗｅｂサーバ３０１と通信するようにしてもよい（以下、同様）。

バックエンドは、クライアント登録依頼を受信すると、クライアントＩＤ（ｃｌｉｅｎｔ＿ｉｄ）と、秘密鍵（ｃｌｉｅｎｔ＿ｓｅｃｒｅｔ）とを発行することによりクライアントを登録する。バックエンドは、クライアントＩＤ（ｃｌｉｅｎｔ＿ｉｄ）と、秘密鍵（ｃｌｉｅｎｔ＿ｓｅｃｒｅｔ）とを、第１通信処理部１１２に応答として送信する（ステップ４ｆ）。なお、秘密鍵（ｃｌｉｅｎｔ＿ｓｅｃｒｅｔ）の発行および送信を省略する構成も可能である。

第１通信処理部１１２のクライアント登録機能は、第２通信処理部１１５に対してクライアント登録が完了した旨の通知を応答し（ステップ３ｆ）、これを受けて、第２通信処理部１１５は、サーバ証明書の登録が完了した旨の通知を応答する（ステップ１ｆ）。

第１通信処理部１１２が、フロントエンドから、第１ネットワーク５０１を介して、リソースアクセスを要求する命令、すなわち、機器の監視・制御命令を受信する（ステップ５）。この段階では、まだフロントエンドは、第１通信処理部１１２へのアクセスを許可されていない状態である。この場合、第１通信処理部１１２の認可移譲機能は、認可画面ＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）へのリダイレクト指示をフロントエンドに応答する（ステップ５ｆ）。認可画面ＵＲＬは、認可画面ＵＲＬは、ユーザ認可処理を行うための画面を提示するために使用するＵＲＬである。このＵＲＬは、Ｗｅｂサービス内のパスである。フロントエンドは、受信したリダイレクト指示に含まれる認可画面ＵＲＬ（ａｕｔｈｚ＿ｕｒｌ）に、リダイレクトする（ステップ６）。

ユーザは、リダイレクトされたＷｅｂサービス上の画面（Ｗｅｂブラウザの画面）で、必要に応じてログイン処理を行ってもよい。ユーザは、当該画面を介して、クライアント（第１通信処理部１１２）に対して、当該Ｗｅｂサービス上のリソース（ユーザ情報など）へのアクセス権限を付与することを認可する（ステップ７）。なお、この要求する権限の範囲を示す情報も、クライアント登録時（ステップ４）に、クライアント自らが指定する。ユーザが許可したことを示す通知が、Ｗｅｂブラウザからフロントエンドを介してバックエンドに送信される（同ステップ７）。

ユーザが認可すると、バックエンドは、ユーザが認可したことを示す認可データとして、認可コード（ａｕｔｈｚ＿ｃｏｄｅ）を生成し、ステップ４で取得済みのｒｅｄｉｒｅｃｔ＿ｕｒｌへこの認可コードを付加したものを、フロントエンドに送る（ステップ６ｆ）。フロントエンドは、ｒｅｄｉｒｅｃｔ＿ｕｒｌに従って、第１通信処理部１１２へリダイレクトし、第１ネットワーク５０１を介して、認可コードを含む認可済通知を、第１通信処理部１１２へ送信する（ステップ８）。このように、バックエンドは、フロントエンドを、ｒｅｄｉｒｅｃｔ＿ｕｒｌから、第１通信処理部１１２へリダイレクトさせることで、認可コード（ａｕｔｈｚ＿ｃｏｄｅ）を第１通信処理部１１２へ送信する。

第１通信処理部１１２のトークン取得機能は、取得した認可コード（ａｕｔｈｚ＿ｃｏｄｅ）と、クライアントＩＤ（ｃｌｉｅｎｔ＿ｉｄ）と、秘密鍵（ｃｌｉｅｎｔ＿ｓｅｃｒｅｔ）とを含む認可トークン取得要求を生成する。許可トークン取得要求は、ユーザ情報の取得要求に相当する。第１通信処理部１１２（のトークン取得機能）は、この要求を、フロントエンドを介してバックエンドに送信する（ステップ９）。

バックエンドは、認可トークン取得要求を受信すると、アクセストークン（ａｃｃｅｓｓ＿ｔｏｋｅｎ）を生成し、当該アクセストークンを、フロントエンドを介して、第１通信処理部１１２に応答する（ステップ９ｆ）。アクセストークンは、許可トークン取得要求に対する許可を表す許可情報である。アクセストークンは、例えば任意の文字列であり、その生成方法は任意でよい。

第１通信処理部１１２のユーザ情報取得機能は、取得したアクセストークン（ａｃｃｅｓｓ＿ｔｏｋｅｎ）を含むユーザ情報取得要求を生成し、この要求をフロントエンドを介して、バックエンドに送信する（ステップ１０）。このユーザ情報取得要求で要求するユーザ情報は、ユーザの属性情報に縛られるものではなく、ユーザの権限でアクセス可能な情報や機能一般を指すものとする。バックエンドは、アクセストークンを検証し、これに対応するユーザ情報を特定して、第１通信処理部１１２に送信する（ステップ１０ｆ）。図ではユーザ情報を、ｕｓｅｒｉｎｆｏで表している。なお、このときアクセストークンには、発行元（Ｗｅｂサーバ３０１）や発行対象（第１通信処理部１１２）を検証するための署名情報が付与されていてもよい。この署名には、例えば、発行元検証のためにＷｅｂサーバ３０１の秘密鍵を、発行対象の検証のために上記ｃｌｉｅｎｔ＿ｓｅｃｒｅｔを用いるなどして、Ｗｅｂサーバ３０１が、自身が、第１通信処理部１１２に対して発行したものであることを検証できるように構成してもよい。

第１通信処理部１１２は、ユーザ情報の取得に成功したら、ログインセッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）を生成し（ステップ１１）、ログインセッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）を含む応答を、フロントエンドに送信する（ステップ８ｆ）。ログインセッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）は、一般的には、ＨＴＴＰのＳｅｔ−Ｃｏｏｋｉｅに設定される。ユーザ情報の取得に成功したことは、第１通信処理部１１２がＷｅｂサーバ３０１を正当なものと判断できることを意味する。

フロントエンドは、ログインセッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）を含む、機器の監視・制御命令を、第１ネットワーク５０１を介して、第１通信処理部１１２に送信する（ステップ１２）。

第１通信処理部１１２は、Ｃｏｏｋｉｅによる認証により、フロントエンドのアクセスを認可することを決定する。第１通信処理部１１２は、配下の機器へ、フロントエンドから受けた監視・制御命令を送信する（ステップ１３）。第１通信処理部１１２は、機器から命令の実行完了通知を受信し（ステップ１３ｆ）、フロントエンドへ命令の実行完了通知を送信する（ステップ１２ｆ）。

以上の手順によって、通信装置１０１内のローカルサーバである第１通信処理部１１２が行うべきアクセス元の検証を、Ｗｅｂサービス側で行うユーザ認証で代替することが実現できている。本実施形態により、通信装置１０１が行うべき認証を、通信装置１０１が搭載された機器へのアクセスが認可されたオリジン上の認証機構に統合することが可能になる。なお、サーバ証明書に基づく認証は、第１〜４の実施形態と同様にして実行すればよい。

上述した手順は、第２実施形態のシーケンス（ＣＳＲ発行要求を受信した場合のシーケンス）を前提としたが、第１実施形態のシーケンス（証明書発行要求を受信した場合のシーケンス）の場合でも、同様にして実施可能である。

本実施形態では、通信装置１０１がゲートウェイ装置に搭載されている例を示したが、たとえば、通信装置１０１が、コンテンツ配信サービス（Ｗｅｂサービス）用のローカルキャッシュデバイスに搭載されることも考えられる。このローカルキャッシュデバイスは、コンテンツ配信サービスのＷｅｂ画面のみからアクセスでき、ローカルキャッシュデバイス側で行う認証は、本実施形態により、コンテンツ配信サービスと統合できる。したがって、正しい視聴権限を持ったユーザだけが、購入済コンテンツや、ウォッチリストに追加したコンテンツを、ローカルキャッシュでき、ローカル通信のみでコンテンツ視聴可能になる（視聴の際にインターネットからダウンロードする必要はない）等の利点がある。

尚、各実施形態の通信装置、操作端末、Ｗｅｂサーバおよび機器登録サーバは、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより、通信装置、操作端末、Ｗｅｂサーバおよび機器登録サーバのそれぞれが備える各機能を実現出来る。このとき、各装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、通信装置、操作端末、Ｗｅｂサーバおよび機器登録サーバのそれぞれが備える記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路 （ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。

別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。

また、用語“ストレージ”は、磁気技術、光学技術、または不揮発性メモリを利用して、永久的にデータを記憶できるに任意の装置を包含してもよい。例えば、ストレージは、ＨＤＤ、光学ディスク、ＳＳＤ等でもよい。

上記に、本発明の一実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０１：通信装置
２０１：操作端末
３０１：Ｗｅｂサーバ
４０１：機器登録サーバ
５０１：第１ネットワーク
６０１：第２ネットワーク
７０１：第３ネットワーク
８０１：第４ネットワーク
１１１：第１通信部
１１２：第１通信処理部
１１３：第１記憶部
１１４：第２通信部
１１５：第２通信処理部
１１６：第２記憶部
１１７：設定部
１１８：認可部
１２４：第４通信処理部
１２３：第４通信部

Claims (18)

1. 第１ネットワークを介して、サーバと通信可能な第１通信部と、
   前記第１ネットワークを介して前記サーバと通信可能であるユーザの操作端末と、第２ネットワークを介して通信可能な第２通信部と、
   前記第１通信部及び前記サーバを介して前記操作端末と認証処理を行い、前記認証処理が成功の場合に、前記第１通信部を介して前記操作端末にリソースを提供する第１処理を実行する第１通信処理部と、
   第２通信処理部であって、
   前記サーバから前記操作端末及び前記第２通信部を介して発行要求を受信し、
   第１鍵で暗号化されたデータは第２鍵で復号可能であり、前記第２鍵で暗号化されたデータは前記第１鍵で復号可能であるという関係を有する、第１鍵および第２鍵を生成し、
   発行対象属性に前記第１通信処理部の識別情報が設定され、前記第１鍵を含み、前記第２鍵により署名された証明書を発行し、
   第１サーバによって生成されかつ前記サーバによって前記発行要求に含められた署名対象データを、自装置と前記第１サーバとの間で事前に共有している第３鍵で署名した署名データを生成し、
   前記署名データと前記証明書とを、前記第２通信部及び前記操作端末を介して、前記サーバに送信する、第２通信処理部と、
   前記証明書の発行を前記ユーザが許可したことを表す許可情報を取得する認可部と、を備え、
   前記署名データが前記第１サーバによって検証された後、前記証明書は前記サーバによって前記操作端末に設定され、
   前記第１通信処理部は、前記第１通信部を介して前記サーバから、送信元が前記操作端末でありかつ前記第１処理の実行を要求する命令を受信した場合に、前記第１通信部及び前記サーバを介して、前記証明書を用いて、前記操作端末との前記認証処理を行い、
   前記第２通信処理部は、前記許可情報が取得された場合のみ、前記証明書が発行または用いられるよう制御する
   通信装置。
2. 前記第２通信処理部は、前記証明書を発行する代わりに、発行対象属性に前記第１通信処理部の識別情報が設定され、かつ前記第１鍵を含む、証明書署名要求を生成し、
   前記第２通信処理部は、前記第２通信部、前記操作端末及び前記サーバを介して、前記第１サーバに前記署名データ及び前記証明書署名要求を送信し、前記第１サーバから前記証明書署名要求が第４鍵により署名された第２証明書を、前記サーバ、前記操作端末及び前記第２通信部を介して、受信し、
   前記認可部は、前記第２証明書の発行または前記証明書署名要求の発行を、前記ユーザが許可したことを表す許可情報を取得し、
   前記第１通信処理部は、前記第２証明書を用いて、前記認証処理を行う
   請求項１に記載の通信装置。
3. 前記発行要求は、前記発行要求の要求元の識別情報として前記サーバの識別情報を含み、
   前記証明書は、複数の属性を含み、前記複数の属性のうちの少なくとも１つは、前記発行要求の要求元の識別情報として前記サーバの識別情報を含む
   請求項１ないし２のいずれか一項に記載の通信装置。
4. 前記発行要求は、前記ユーザの識別情報を含み、
   前記証明書は、複数の属性を含み、前記複数の属性のうちの少なくとも１つは、前記ユーザの識別情報を含む
   請求項１ないし３のいずれか一項に記載の通信装置。
5. 前記認可部は、前記通信装置が搭載される機器の物理インタフェースを介して、前記許可情報を取得する
   請求項１ないし４のいずれか一項に記載の通信装置。
6. 前記第２通信処理部は、前記発行要求の受信に応じて、第５鍵および第５鍵と対になる第６鍵と、前記第１通信処理部の識別情報とを用いて、前記ユーザが認可に関する意思表示を行うための画面を前記ユーザに表示するための一時的な証明書である第３証明書を発行し、
   前記第２通信処理部は、前記第３証明書を、前記第２通信部を介して前記操作端末に送信し、
   前記第１通信部は、前記第１ネットワークを介して、前記操作端末と通信可能であり、
   前記第１通信処理部は、前記第１通信部を介して前記操作端末と前記第３証明書に基づく認証を行い、
   前記認可部は、前記第３証明書に基づく前記認証が成功した後、前記操作端末に認可に関する意思表示を行うための画面を表示するよう制御し、前記ユーザによる前記画面への入力を介して、前記許可情報を取得する
   請求項１ないし４のいずれか一項に記載の通信装置。
7. 前記第２通信処理部は、
   第２署名対象データを、前記第２通信部及び前記操作端末を介して前記サーバに送信し、
   自装置と前記第１サーバとの間で事前に共有している第８鍵で署名された前記第２署名対象データである第２署名データと、前記サーバの識別情報と、前記サーバにより生成された公開鍵とを含む第２証明書署名要求を、前記第２通信部を介して前記サーバから受信し、
   前記第８鍵を用いて前記第２署名データを検証し、前記第２署名データの検証が成功した場合に、前記第２証明書署名要求を、前記第２鍵で署名することにより、第４証明書を発行し、
   前記第４証明書を、前記第２通信部及び前記操作端末を介して、前記サーバに送信し、
   前記第１通信処理部は、前記第４証明書に基づき、前記発行要求の要求元である前記サーバを認証する処理を行う
   請求項１ないし６のいずれか一項に記載の通信装置。
8. 前記第１通信処理部が、前記第１通信部を介して前記サーバに、前記第１通信処理部の登録要求を送信して、前記第１通信部を介して前記サーバから第１登録情報を受信し、
   前記第１通信処理部が、前記第１通信部を介して、前記サーバからユーザが、ユーザの権限で取得可能な情報であるユーザ情報の取得を認可したことを示す認可データを含む通知を受信し、
   前記第１通信処理部が、前記第１登録情報と、前記認可データとを含む、前記ユーザ情報の取得要求を、前記第１通信部を介して、前記サーバに送信し、
   前記第１通信処理部が、前記サーバから前記第１通信部を介して、前記取得要求に対する許可通知を受信した場合に、前記サーバから前記第１通信部を介して前記ユーザ情報を取得し、
   前記第１通信処理部は、前記ユーザ情報を取得できた場合、前記発行要求の要求元を正当なものと決定し、前記第１通信処理部へのアクセスを許可する
   請求項１ないし６のいずれか一項に記載の通信装置。
9. 前記第１鍵は公開鍵、前記第２鍵は秘密鍵、前記第３鍵は事前共有鍵、
   請求項１ないし８のいずれか一項に記載の通信装置。
10. 前記第４鍵は、前記第２鍵とは別の秘密鍵である
    請求項２に記載の通信装置。
11. 前記第５鍵は、公開鍵、前記第６鍵は、秘密鍵である
    請求項６に記載の通信装置。
12. 前記第３証明書は、前記ユーザ認可用の一時的な自己署名サーバ証明書である
    請求項６に記載の通信装置。
13. 前記第４証明書は、クライアント証明書である
    請求項７に記載の通信装置。
14. 請求項１ないし１３のいずれか一項に記載の通信装置と、
    前記第１サーバと、を備え、
    前記第１サーバは、前記サーバを介して、前記署名対象データを前記通信装置に送信し、前記署名データを前記サーバを介して前記通信装置から受信し、前記第３鍵と対になる第７鍵により前記署名データを検証する
    通信システム。
15. 第１ネットワークを介して、サーバと通信可能な第１通信部と、前記第１ネットワークを介して前記サーバと通信可能であるユーザの操作端末と第２ネットワークを介して通信可能な第２通信部と、を用いた通信方法であって、
    第２通信処理部が、前記サーバから前記操作端末及び前記第２通信部を介して発行要求を受信し、
    前記第２通信処理部が、第１鍵で暗号化されたデータは第２鍵で復号可能であり、前記第２鍵で暗号化されたデータは前記第１鍵で復号可能であるという関係を有する、第１鍵および第２鍵を生成し、
    前記第２通信処理部が、発行対象属性に第１通信処理部の識別情報が設定され、前記第１鍵を含み、前記第２鍵により署名された証明書を発行し、
    前記第２通信処理部が、第１サーバによって生成されかつ前記サーバによって前記発行要求に含められた署名対象データを、自装置と前記第１サーバとの間で事前に共有している第３鍵で署名した署名データを生成し、
    前記第２通信処理部が、前記署名データと前記証明書とを、前記第２通信部及び前記操作端末を介して、前記サーバに送信し、
    認可部が、前記証明書の発行を前記ユーザが許可したことを表す許可情報を取得し、
    前記署名データは前記第１サーバによって検証された後、前記証明書は前記サーバによって前記操作端末に設定されるものであり、
    前記第１通信処理部が、前記第１通信部を介して前記サーバから、送信元が前記操作端末でありかつ前記操作端末にリソースを提供する第１処理の実行を要求する命令を受信した場合に、前記第１通信部及び前記サーバを介して、前記証明書を用いて、前記操作端末との認証処理を行い、前記認証処理が成功の場合に、前記第１通信部を介して前記操作端末にリソースを提供する前記第１処理を実行し、
    前記第２通信処理部が、前記許可情報が取得された場合のみ、前記証明書が発行または用いられるよう制御する
    通信方法。
16. 前記第２通信処理部が、前記証明書を発行する代わりに、発行対象属性に前記第１通信処理部の識別情報が設定され、かつ前記第１鍵を含む、証明書署名要求を生成し、
    前記第２通信処理部が、前記第２通信部、前記操作端末及び前記サーバを介して、第１サーバに前記署名データ及び前記証明書署名要求を送信し、前記第１サーバから前記証明書署名要求が第４鍵により署名された第２証明書を、前記サーバ、前記操作端末及び前記第２通信部を介して、前記第２通信部を介して前記操作端末から受信し、
    前記第１通信処理部は、前記第２証明書を用いて、前記認証処理を行い、
    前記認可部が、前記第２証明書の発行または前記証明書署名要求の発行を、前記ユーザが許可したことを表す許可情報を取得する
    請求項１５に記載の通信方法。
17. 第１ネットワークを介して、サーバと通信可能な第１通信部と、前記第１ネットワークを介して前記サーバと通信可能であるユーザの操作端末と第２ネットワークを介して通信可能な第２通信部と、を備えたコンピュータに実行させるためのプログラムであって、
    第２通信処理部が、前記サーバから前記操作端末及び前記第２通信部を介して発行要求を受信するステップと、
    前記第２通信処理部が、第１鍵で暗号化されたデータは第２鍵で復号可能であり、前記第２鍵で暗号化されたデータは前記第１鍵で復号可能であるという関係を有する、第１鍵および第２鍵を生成するステップと、
    前記第２通信処理部が、発行対象属性に第１通信処理部の識別情報が設定され、前記第１鍵を含み、前記第２鍵により署名された証明書を発行するステップと、
    前記第２通信処理部が、第１サーバによって生成されかつ前記サーバによって前記発行要求に含められた署名対象データを、自装置と前記第１サーバとの間で事前に共有している第３鍵で署名した署名データを生成するステップと、
    前記第２通信処理部が、前記署名データと前記証明書とを、前記第２通信部及び前記操作端末を介して、前記サーバに送信するステップと、
    認可部が、前記証明書の発行を前記ユーザが許可したことを表す許可情報を取得するステップと、
    前記署名データは前記第１サーバによって検証された後、前記証明書は前記サーバによって前記操作端末に設定されるものであり、
    前記第１通信処理部が、前記第１通信部を介して前記サーバから、送信元が前記操作端末でありかつ前記操作端末にリソースを提供する第１処理の実行を要求する命令を受信した場合に、前記第１通信部及び前記サーバを介して、前記証明書を用いて、前記操作端末との認証処理を行い、前記認証処理が成功の場合に、前記第１通信部を介して前記操作端末にリソースを提供する前記第１処理を実行するステップと、
    前記第２通信処理部が、前記許可情報が取得された場合のみ、前記証明書が発行または用いられるよう制御するステップと
    を備えたプログラム。
18. 前記第２通信処理部が、前記証明書を発行する代わりに、発行対象属性に前記第１通信処理部の識別情報が設定され、かつ前記第１鍵を含む、証明書署名要求を生成するステップと、
    前記第２通信処理部が、前記第２通信部、前記操作端末及び前記サーバを介して、第１サーバに前記署名データ及び前記証明書署名要求を送信し、前記第１サーバから前記証明書署名要求が第４鍵により署名された第２証明書を、前記サーバ、前記操作端末及び前記第２通信部を介して、前記第２通信部を介して前記操作端末から受信するステップと、
    前記第１通信処理部は、前記第２証明書を用いて、前記認証処理を行うステップと、
    前記認可部が、前記第２証明書の発行または前記証明書署名要求の発行を、前記ユーザが許可したことを表す許可情報を取得するステップと、
    を前記コンピュータに実行させるための請求項１７に記載のプログラム。

Images