ネットワークデバイス
【課題】ネットワークを介して情報を配信するネットワークシステムにおいて、配信先の機器でＳＳＬサーバの設定がされていない場合でも、柔軟にセキュアな情報配信を実現出来るようにする。
【解決手段】各ネットワークデバイスに、暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段を備え、ネゴシエーションを行って配信先がＳＳＬクライアントとして配信元機器に対して情報を取得するように切り替え、暗号通信を確立する。
【解決手段】各ネットワークデバイスに、暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段を備え、ネゴシエーションを行って配信先がＳＳＬクライアントとして配信元機器に対して情報を取得するように切り替え、暗号通信を確立する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク環境に接続され情報を暗号化し送受信する送受信機能を持つネットワークデバイス等が、通信相手先の状態に応じてサーバ型とクライアント型の送受信手段を切り替える制御手段と有し、通信相手先でサーバ型セキュリティ設定がされていない状態でもセキュアに情報を配信する技術に関する。
【背景技術】
【０００２】
近年、イーサネット（登録商標）ワークの一般化や高機能化に伴い、同一リンク内に多数のパーソナルコンピュータ（ＰＣ）や印刷装置などネットワークデバイスが存在している。
【０００３】
大きな企業にもなると、何千台というＰＣや印刷装置が同一リンク内に存在している。
【０００４】
その中で、ドメインネームサーバ（ＤＮＳ）アドレスやゲートウェイアドレス、また印刷装置の場合ならばアドレス帳設定など機器で共通の設定にできる項目が存在する。従来ではこれらの設定をユーザー、あるいはネットワーク管理者が一台一台手作業で登録処理を行っており、非常に負荷のかかる作業であった。
【０００５】
しかし近年は、ウェブサービスを利用した情報配信機能を利用して、情報配信サーバから同一リンクの機器に対して共通情報を配信する技術が一般化されている。このリンク図を図１に示す。配信元機器Ａは複数の配信先機器ＢおよびＣなどに対して、定期的あるいは指示があった場合に情報を配信する。具定期には、ＨＴＴＰプロトコル上で動作するＳＯＡＰやＲＥＳＴなどの技術を利用して、メッセージデータのボディ部に情報を格納して送信する。このとき、機密情報などが含まれる場合は、ＳＳＬなどを使用して通路を暗号化して送信する。
【０００６】
前記情報配信のシーケンスを図２に示す。まず情報を配信する機器は、配信先のＩＰアドレスを知っておく必要がある。配信先情報は、予め配信機器に登録しておいても、配信する際にマルチキャストなどを利用してそのつど配信先を設定してもよい。
【０００７】
配信元機器は、配信先機器に対してＨＴＴＰリクエストを送信し、配信先機器は自身が情報を配信される設定になっていれば、ＨＴＴＰレスポンスを送信し、その後ＳＯＡＰメッセージを介して共通情報を配信する。配信された機器はその情報を自身のＨＤＤやＳＲＡＭなどの不揮発性記憶装置に保存し、その設定を有効にする。配信元機器は、設定されている配信先機器の数分だけ前記処理を繰り返し、最終的に同一リンク内の全ての機器に共通情報を配信することができる。このとき、情報をＳＳＬで配信する設定がされていればＨＴＴＰリクエストはＳＳＬネゴシエーションとなる。このときの送信元機器Ａのフローチャートを図３に示す。配信先はＳＳＬサーバとして機能を有するので鍵や証明書などの設定が予めされている必要があり、配信元はＳＳＬクライアントとなる。フローＳ３２において、配信先がＳＳＬネゴシエーションの了承を得たら、配信元機器は共通鍵を使用して情報を暗号化し、配信元に送信する。配信先機器は、共通鍵を使用して情報を復号化することで、セキュアに情報を送受信することができる。しかし、配信先機器で鍵や証明書などＳＳＬサーバの設定がされていない場合は当然ネゴシエーションに失敗するために、フローＳ３２のようにその場合は情報送信をあきらめる。例えば特許文献１のように、プッシュ型配信とプル型配信を切り替える方法も提案されているが、この前例ではＳＳＬなどセキュリティが必要な場合に対しては有効ではない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許登録第３８６４２５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、前記従来技術の問題点として、ＳＳＬを使用して配信する設定がなされていた場合に、配信先でＳＳＬサーバの設定間違いや設定忘れがあった場合に、ＳＳＬネゴシエーションに失敗し、情報を配信できないという問題がある。
【００１０】
前述のように、大きな企業などでは何千、何百台の印刷装置が設置されており、その一つ一つにＳＳＬサーバとしての機能を有効にして鍵や証明書を登録することは、ネットワーク管理者などが手作業で行わなければならない。
【課題を解決するための手段】
【００１１】
上記従来の課題を解決するために本発明に係る第１の発明は、
通信回線を介して、外部機器との情報の送受信を行うことができるネットワークデバイスにおいて、
前記外部機器との情報の送受信を行うネットワークプロトコルスタックを搭載し、ネットワークデータのパケットをやり取りする送受信手段と、
情報をウェブサービスのパケット形式で送受信する送受信手段と、
前記パケットを暗号化復号化する暗号処理手段と、
前記暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段と、
前記ネゴシエーションに失敗した場合、通信相手先に暗号通信を確立させる命令を送信する送信手段と、
前記命令を受信した場合に、通信相手先に対して暗号通信を確立するためのネゴシエーションを行う制御手段を有することを特徴とする。
【発明の効果】
【００１２】
本発明を実現することによって、従来セキュアに情報を配信する際に配信先のＳＳＬ設定サーバ設定がされていないと情報を配信できないという問題があったが、ＳＳＬクライアントとして情報を取得させることで、配信先機器で鍵や証明書設定がされていなくてもセキュアに情報を配信することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施例におけるネットワーク構成図を示す図である。
【図２】本発明の従来技術における情報配信のシーケンス図である。
【図３】本発明の従来技術における情報配信元機器のフローチャートを示す図である。
【図４】本発明の実施例におけるハードウェアおよびソフトウェア構成図である。
【図５】本発明の第１実施例における情報配信のシーケンス図である。
【図６】本発明の第１実施例におけるサーバ型とクライアント型を切り替える命令コマンドのパケットフォーマットを示す図である。
【図７】本発明の第１実施例におけるコマンド種別を表す対応表である。
【図８】本発明の第１実施例における情報要求を表すパケットフォーマットを示す図である。
【図９】本発明の第１実施例における情報要求に対する送信のパケットフォーマットを示す図である。
【図１０】本発明の第１実施例における情報の識別子対応表である。
【図１１】本発明の第１実施例における送信元機器の処理のフローチャートを示す図である。
【図１２】本発明の第１実施例における送信先機器の処理のフローチャートを示す図である。
【図１３】本発明の第２実施例におけるサーバ型とクライアント型を切り替える命令コマンドのパケットフォーマットの改変例を示す図である。
【図１４】本発明の第２実施例における情報要求を表すパケットフォーマットの改変例を示す図である。
【図１５】本発明の第２実施例における配信ＩＤと配信先、配信内容を管理する管理表を示す図である。
【発明を実施するための形態】
【００１４】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００１５】
図４は、本発明の実施例におけるデジタル複合機のハードウェア構成を示すブロック図である。CPU101は、デジタル複合機のソフトウェアプログラムを実行し、装置全体の制御を行う。ROM102は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。RAM103は、ランダムアクセスメモリであり、CPU101が装置を制御する際に、一時的なデータの格納などに使用する。HDD108は、ハードディスクドライブであり、印刷データの格納など、様々なデータの格納に使用する。タイマ112は、タイマ処理における経過時刻の管理を行う。プリンタI/F制御部104は、プリンタ110を制御する装置である。NVRAM105は、不揮発性のメモリでありデジタル複合機の各種設定値を保存するためのものである。パネル制御部106は、オペレーションパネル109を制御し、各種情報の表示、使用者からの指示入力を行う。ネットワークI/F制御部107は、LAN111とのデータの送受信を制御する。バス108は、CPU101、ROM102、RAM103、HDD108、タイマ112、プリンタI/F制御部104、NVRAM105、パネル制御部106、ネットワークI/F制御部107が接続され、CPU101からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。
【００１６】
本実施例では、配信先でＳＳＬサーバの設定がされていない場合でも、セキュアに情報を配信する技術について図５のシーケンス図に基づき記述する。
【００１７】
まずフローＳ２０１において、配信元機器Ａは情報を配信する際、従来と同様に配信先機器Ｂに対してＳＳＬネゴシエーション開始パケットを開始する。配信先でＳＳＬサーバの設定がされていれば、ネゴシエーション完了のパケットを配信元機器Ａは受信し、その後は配信情報をウェブサービスとしてＳＳＬを介して送信する。これは図２で説明したとおり従来技術の動作となる。
【００１８】
一方、フローＳ２０２において配信先機器Ｂからネゴシエーション失敗のパケットを受信した場合は、従来技術のようにここで処理を終了させるのではなく、配信先機器Ｂに対して、配信先機器Ｂが配信元機器Ａに情報を取得しにくるような命令コマンドを送信する。この命令コマンドのプロトコルは厳密には定義しないが、配信先と配信元でお互いに処理可能なことと、配信情報がウェブサービスを利用しているのでＨＴＴＰ上で動作するプロトコルが望ましい。また、この命令コマンドには配信元機器が配信する予定であった情報の識別子も格納している。
【００１９】
配信先機器Ｂは、この命令コマンドを受信したら、Ｓ２０４において自身がＳＳＬクライアントとなり、配信元機器Ａに対してＳＳＬネゴシエーションを開始する。
【００２０】
配信元機器ＡはＳＳＬサーバの設定が有効になっているため、Ｓ２０５においてＳＳＬネゴシエーションを受け付ける。フローＳ２０７おいて、配信先機器Ｂは命令コマンドに格納されている識別子を抽出し、その識別子を要求するようなリクエストパケットを作成し、送付された公開鍵を用いてパケットを暗号化して配信元に送信する。Ｓ２０８において配信元機器はまず受信パケットを復号化し、パケットを解釈する。リクエストパケットで要求されている識別子の情報を格納したパケットを作成し、同様に暗号化してリプライを行う。
【００２１】
この一連の処理に従って配信先機器はＳＳＬサーバの設定がされていなくとも、自身がＳＳＬクライアントになることでセキュアに情報を送受信することが実現できる。
【００２２】
図６は、前記配信元機器が送信する命令コマンドのパケットフォーマット一例を示す。ＨＴＴＰのボディ部に、コマンド種別を格納する領域が用意され、ここに相手先に情報を取得するように指示する意図のＩＤを格納する。また、データ領域には、配信する情報識別子の総数を意味する箇所と、識別子を格納する。コマンド種別の対応表を図７に示す。例えば、コマンド種別0x001はＳＳＬサーバとＳＳＬクライアントの切替命令を意味するコマンドであり、コマンド種別0x002は情報要求リクエストを意味するコマンド、コマンド種別0x003は情報要求リクエストに対するリプライを意味するコマンドである。
【００２３】
図８は、前記命令コマンドを受信した配信先機器が、前記パケットから識別子情報を抽出し情報リクエストパケットを作成する場合のパケットフォーマットの一例である。コマンド種別には、要求を意味するＩＤを格納し、実際のどの情報が欲しいかはデータ領域の識別子によって表現している。
【００２４】
図９は、配信元機器が前記リクエストパケットを受信した場合の、返信用パケットフォーマットの一例である。コマンド種別には、返答を意味するＩＤを格納し、要求された識別子の値を格納して送信する。
【００２５】
このとき、配信先と配信元では図１０のような識別子対応表を予めプログラムに組み込まれているため、識別子の取り違い等は発生することはない。
【００２６】
図１１には配信元機器の処理のフローチャートを示す。
【００２７】
まず配信元機器ＡはフローＳ１００１において、配信する情報があるかどうかを判別する。情報配信は、定期的あるいは指示があった場合に配信を行う。
【００２８】
フローＳ１００１において配信する情報があると判断した場合は、フローＳ１００２において、予め登録されている配信先機器に対してユニキャストでＳＳＬネゴシエーション開始パケットを送信する。フローＳ１００３において、リプライパケットからネゴシエーションが成功したか失敗したかを判別し、成功の場合は従来技術と同様にフローＳ１００４において送信情報データを暗号化して送信先機器に対して送信する。
【００２９】
フローＳ１００３において、ネゴシエーションが失敗した場合は、フローＳ１００７において命令コマンドを配信先機器に対して送信する。その後はフローＳ１００８においてＳＳＬネゴシエーション開始パケットが来るのを待つ。ＳＳＬネゴシエーションパケットが受信できなかった場合は、処理を終了する。一方、ネゴシエーションパケットを受信した場合は、受信完了のリプライを行いネゴシエーションを完了させセキュア通信路を確立する。
【００３０】
次にフローＳ１０１０において、ＳＳＬで暗号化された情報リクエストパケットが受信するのを待つ。パケットの受信がない場合はそのまま処理を終了する。また、パケット受信した場合は、フローＳ１０１１において共通鍵を使用してパケットデータを復号化し、要求されているリクエスト識別子を解釈し、該当する設定値を記憶装置から抽出する。次にフローＳ１０１２において、パケットデータを暗号化して配信先機器に送信する。この処理をリクエストデータがなくなるまで繰り返す。
【００３１】
一方、図１２には配信先機器の処理のフローチャートを示す。
【００３２】
まずフローＳ２００１において配信元機器からＳＳＬネゴシエーションの要求を受信した場合、自身にＳＳＬサーバの設定がされているかどうかを判断する。具体的には鍵と証明書が予め作成されているかどうかを判断する。このとき、設定がされていた場合は、従来技術と同様に、フローＳ２００３においてネゴシエーションに対して正常リプライを送信しＳＳＬ通信路を確立する。そしてフローＳ２００４以降で配信元機器から送付される情報がなくなるまで受信を繰り返し、受信した情報を自身の設定に反映させる。
【００３３】
一方、フローＳ２００２において自身のＳＳＬサーバが設定されていない場合は、フローＳ２００７においてネゴシエーション拒否のパケットを送信する。この後配信元機器が本発明の機能を有していれば、フローＳ２００８において命令コマンドが送信され、配信先機器はこの命令コマンドを受信する。フローＳ２００９において、命令コマンドを受信した配信先機器は、配信元機器に対してＳＳＬネゴシエーション開始要求パケットを送信する。この要求に対してネゴシエーション拒否のリプライがあった場合は処理を終了する。一方ネゴシエーション完了の通知があった場合は、フローＳ２０１１において命令コマンドで格納されている識別子を格納して、情報リクエストデータを作成し、共通鍵で暗号化を行う。フローＳ２０１２においてリクエストパケットを送信した後、フローＳ２０１３において受信データを待つ。リプライパケットを受信したら、フローＳ２０１４においてデータを復号化し、要求した識別子に対応した値を抽出し、その設定値を自身の機器に反映させる。フローＳ２０１３において受信データがまだある場合は、データ終了までこの処理を繰り返す。
【実施例２】
【００３４】
本章では、実施例１で説明した配信元と配信先がやり取りするパケットフォーマットを改変し、より柔軟でトラフィックを軽減できる実施例について説明する。
【００３５】
図１３は、配信元機器が送信する命令コマンドのパケットフォーマットの改変例である。コマンド種別の領域には図６と同様の値が格納されるが、データ領域には、配信ＩＤのみを格納する。このパケットフォーマットを受信した配信先機器は図１４のリクエストパケットフォーマットに従って、情報要求を行う。データの領域の配信ＩＤは前記命令コマンドで指定された配信ＩＤと同じ値を格納しておく。
【００３６】
前記リクエストパケットを受信した配信元機器は、図１５で示すような管理テーブル表に従って、配信ＩＤに対応した識別子と識別子情報を図９のパケットフォーマットで返信する。
【００３７】
この実施例の場合では、配信元機器がどの配信先にどの情報を配信するべきかを全て図１５の管理テーブル表で管理を行っているため、実施例１のように配信先機器に情報識別子を意識させる必要はなく、配信先機器の負荷とトラフィックの軽減につながる。
【００３８】
配信元機器は、命令コマンドを配信先機器に対して送信する際、どの配信先に対してどの配信ＩＤを割り振ったかを管理テーブル表に書き込みをすることによって記憶しておく。
【実施例３】
【００３９】
前記実施例では、配信元機器は常にＳＳＬが有効になっているウェブサーバとして動作している必要がある。しかし、配信先機器がＳＳＬクライアントにならない限りウェブサーバとして機能は不要になるため、無駄なポートを開いてセキュリティ上の危惧がある。
【００４０】
そのため、本実施例では、図５のフローＳ２０３において配信元機器が配信先機器に対して命令コマンドを送信した時点で初めてＳＳＬおよびＨＴＴＰポートを開くような制御処理を行う。そして、図５の一連のシーケンスが終了し、情報をセキュアに配信することが完了したら配信元機器にウェブアクセスしてくる機器はいないはずなので、再びＳＳＬおよびＨＴＴＰポートを閉じる。この処理によって、必要な時にしかポートを開閉しないので、配信元機器のセキュリティを向上することができる。
【技術分野】
【０００１】
本発明は、ネットワーク環境に接続され情報を暗号化し送受信する送受信機能を持つネットワークデバイス等が、通信相手先の状態に応じてサーバ型とクライアント型の送受信手段を切り替える制御手段と有し、通信相手先でサーバ型セキュリティ設定がされていない状態でもセキュアに情報を配信する技術に関する。
【背景技術】
【０００２】
近年、イーサネット（登録商標）ワークの一般化や高機能化に伴い、同一リンク内に多数のパーソナルコンピュータ（ＰＣ）や印刷装置などネットワークデバイスが存在している。
【０００３】
大きな企業にもなると、何千台というＰＣや印刷装置が同一リンク内に存在している。
【０００４】
その中で、ドメインネームサーバ（ＤＮＳ）アドレスやゲートウェイアドレス、また印刷装置の場合ならばアドレス帳設定など機器で共通の設定にできる項目が存在する。従来ではこれらの設定をユーザー、あるいはネットワーク管理者が一台一台手作業で登録処理を行っており、非常に負荷のかかる作業であった。
【０００５】
しかし近年は、ウェブサービスを利用した情報配信機能を利用して、情報配信サーバから同一リンクの機器に対して共通情報を配信する技術が一般化されている。このリンク図を図１に示す。配信元機器Ａは複数の配信先機器ＢおよびＣなどに対して、定期的あるいは指示があった場合に情報を配信する。具定期には、ＨＴＴＰプロトコル上で動作するＳＯＡＰやＲＥＳＴなどの技術を利用して、メッセージデータのボディ部に情報を格納して送信する。このとき、機密情報などが含まれる場合は、ＳＳＬなどを使用して通路を暗号化して送信する。
【０００６】
前記情報配信のシーケンスを図２に示す。まず情報を配信する機器は、配信先のＩＰアドレスを知っておく必要がある。配信先情報は、予め配信機器に登録しておいても、配信する際にマルチキャストなどを利用してそのつど配信先を設定してもよい。
【０００７】
配信元機器は、配信先機器に対してＨＴＴＰリクエストを送信し、配信先機器は自身が情報を配信される設定になっていれば、ＨＴＴＰレスポンスを送信し、その後ＳＯＡＰメッセージを介して共通情報を配信する。配信された機器はその情報を自身のＨＤＤやＳＲＡＭなどの不揮発性記憶装置に保存し、その設定を有効にする。配信元機器は、設定されている配信先機器の数分だけ前記処理を繰り返し、最終的に同一リンク内の全ての機器に共通情報を配信することができる。このとき、情報をＳＳＬで配信する設定がされていればＨＴＴＰリクエストはＳＳＬネゴシエーションとなる。このときの送信元機器Ａのフローチャートを図３に示す。配信先はＳＳＬサーバとして機能を有するので鍵や証明書などの設定が予めされている必要があり、配信元はＳＳＬクライアントとなる。フローＳ３２において、配信先がＳＳＬネゴシエーションの了承を得たら、配信元機器は共通鍵を使用して情報を暗号化し、配信元に送信する。配信先機器は、共通鍵を使用して情報を復号化することで、セキュアに情報を送受信することができる。しかし、配信先機器で鍵や証明書などＳＳＬサーバの設定がされていない場合は当然ネゴシエーションに失敗するために、フローＳ３２のようにその場合は情報送信をあきらめる。例えば特許文献１のように、プッシュ型配信とプル型配信を切り替える方法も提案されているが、この前例ではＳＳＬなどセキュリティが必要な場合に対しては有効ではない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許登録第３８６４２５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、前記従来技術の問題点として、ＳＳＬを使用して配信する設定がなされていた場合に、配信先でＳＳＬサーバの設定間違いや設定忘れがあった場合に、ＳＳＬネゴシエーションに失敗し、情報を配信できないという問題がある。
【００１０】
前述のように、大きな企業などでは何千、何百台の印刷装置が設置されており、その一つ一つにＳＳＬサーバとしての機能を有効にして鍵や証明書を登録することは、ネットワーク管理者などが手作業で行わなければならない。
【課題を解決するための手段】
【００１１】
上記従来の課題を解決するために本発明に係る第１の発明は、
通信回線を介して、外部機器との情報の送受信を行うことができるネットワークデバイスにおいて、
前記外部機器との情報の送受信を行うネットワークプロトコルスタックを搭載し、ネットワークデータのパケットをやり取りする送受信手段と、
情報をウェブサービスのパケット形式で送受信する送受信手段と、
前記パケットを暗号化復号化する暗号処理手段と、
前記暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段と、
前記ネゴシエーションに失敗した場合、通信相手先に暗号通信を確立させる命令を送信する送信手段と、
前記命令を受信した場合に、通信相手先に対して暗号通信を確立するためのネゴシエーションを行う制御手段を有することを特徴とする。
【発明の効果】
【００１２】
本発明を実現することによって、従来セキュアに情報を配信する際に配信先のＳＳＬ設定サーバ設定がされていないと情報を配信できないという問題があったが、ＳＳＬクライアントとして情報を取得させることで、配信先機器で鍵や証明書設定がされていなくてもセキュアに情報を配信することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施例におけるネットワーク構成図を示す図である。
【図２】本発明の従来技術における情報配信のシーケンス図である。
【図３】本発明の従来技術における情報配信元機器のフローチャートを示す図である。
【図４】本発明の実施例におけるハードウェアおよびソフトウェア構成図である。
【図５】本発明の第１実施例における情報配信のシーケンス図である。
【図６】本発明の第１実施例におけるサーバ型とクライアント型を切り替える命令コマンドのパケットフォーマットを示す図である。
【図７】本発明の第１実施例におけるコマンド種別を表す対応表である。
【図８】本発明の第１実施例における情報要求を表すパケットフォーマットを示す図である。
【図９】本発明の第１実施例における情報要求に対する送信のパケットフォーマットを示す図である。
【図１０】本発明の第１実施例における情報の識別子対応表である。
【図１１】本発明の第１実施例における送信元機器の処理のフローチャートを示す図である。
【図１２】本発明の第１実施例における送信先機器の処理のフローチャートを示す図である。
【図１３】本発明の第２実施例におけるサーバ型とクライアント型を切り替える命令コマンドのパケットフォーマットの改変例を示す図である。
【図１４】本発明の第２実施例における情報要求を表すパケットフォーマットの改変例を示す図である。
【図１５】本発明の第２実施例における配信ＩＤと配信先、配信内容を管理する管理表を示す図である。
【発明を実施するための形態】
【００１４】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００１５】
図４は、本発明の実施例におけるデジタル複合機のハードウェア構成を示すブロック図である。CPU101は、デジタル複合機のソフトウェアプログラムを実行し、装置全体の制御を行う。ROM102は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。RAM103は、ランダムアクセスメモリであり、CPU101が装置を制御する際に、一時的なデータの格納などに使用する。HDD108は、ハードディスクドライブであり、印刷データの格納など、様々なデータの格納に使用する。タイマ112は、タイマ処理における経過時刻の管理を行う。プリンタI/F制御部104は、プリンタ110を制御する装置である。NVRAM105は、不揮発性のメモリでありデジタル複合機の各種設定値を保存するためのものである。パネル制御部106は、オペレーションパネル109を制御し、各種情報の表示、使用者からの指示入力を行う。ネットワークI/F制御部107は、LAN111とのデータの送受信を制御する。バス108は、CPU101、ROM102、RAM103、HDD108、タイマ112、プリンタI/F制御部104、NVRAM105、パネル制御部106、ネットワークI/F制御部107が接続され、CPU101からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。
【００１６】
本実施例では、配信先でＳＳＬサーバの設定がされていない場合でも、セキュアに情報を配信する技術について図５のシーケンス図に基づき記述する。
【００１７】
まずフローＳ２０１において、配信元機器Ａは情報を配信する際、従来と同様に配信先機器Ｂに対してＳＳＬネゴシエーション開始パケットを開始する。配信先でＳＳＬサーバの設定がされていれば、ネゴシエーション完了のパケットを配信元機器Ａは受信し、その後は配信情報をウェブサービスとしてＳＳＬを介して送信する。これは図２で説明したとおり従来技術の動作となる。
【００１８】
一方、フローＳ２０２において配信先機器Ｂからネゴシエーション失敗のパケットを受信した場合は、従来技術のようにここで処理を終了させるのではなく、配信先機器Ｂに対して、配信先機器Ｂが配信元機器Ａに情報を取得しにくるような命令コマンドを送信する。この命令コマンドのプロトコルは厳密には定義しないが、配信先と配信元でお互いに処理可能なことと、配信情報がウェブサービスを利用しているのでＨＴＴＰ上で動作するプロトコルが望ましい。また、この命令コマンドには配信元機器が配信する予定であった情報の識別子も格納している。
【００１９】
配信先機器Ｂは、この命令コマンドを受信したら、Ｓ２０４において自身がＳＳＬクライアントとなり、配信元機器Ａに対してＳＳＬネゴシエーションを開始する。
【００２０】
配信元機器ＡはＳＳＬサーバの設定が有効になっているため、Ｓ２０５においてＳＳＬネゴシエーションを受け付ける。フローＳ２０７おいて、配信先機器Ｂは命令コマンドに格納されている識別子を抽出し、その識別子を要求するようなリクエストパケットを作成し、送付された公開鍵を用いてパケットを暗号化して配信元に送信する。Ｓ２０８において配信元機器はまず受信パケットを復号化し、パケットを解釈する。リクエストパケットで要求されている識別子の情報を格納したパケットを作成し、同様に暗号化してリプライを行う。
【００２１】
この一連の処理に従って配信先機器はＳＳＬサーバの設定がされていなくとも、自身がＳＳＬクライアントになることでセキュアに情報を送受信することが実現できる。
【００２２】
図６は、前記配信元機器が送信する命令コマンドのパケットフォーマット一例を示す。ＨＴＴＰのボディ部に、コマンド種別を格納する領域が用意され、ここに相手先に情報を取得するように指示する意図のＩＤを格納する。また、データ領域には、配信する情報識別子の総数を意味する箇所と、識別子を格納する。コマンド種別の対応表を図７に示す。例えば、コマンド種別0x001はＳＳＬサーバとＳＳＬクライアントの切替命令を意味するコマンドであり、コマンド種別0x002は情報要求リクエストを意味するコマンド、コマンド種別0x003は情報要求リクエストに対するリプライを意味するコマンドである。
【００２３】
図８は、前記命令コマンドを受信した配信先機器が、前記パケットから識別子情報を抽出し情報リクエストパケットを作成する場合のパケットフォーマットの一例である。コマンド種別には、要求を意味するＩＤを格納し、実際のどの情報が欲しいかはデータ領域の識別子によって表現している。
【００２４】
図９は、配信元機器が前記リクエストパケットを受信した場合の、返信用パケットフォーマットの一例である。コマンド種別には、返答を意味するＩＤを格納し、要求された識別子の値を格納して送信する。
【００２５】
このとき、配信先と配信元では図１０のような識別子対応表を予めプログラムに組み込まれているため、識別子の取り違い等は発生することはない。
【００２６】
図１１には配信元機器の処理のフローチャートを示す。
【００２７】
まず配信元機器ＡはフローＳ１００１において、配信する情報があるかどうかを判別する。情報配信は、定期的あるいは指示があった場合に配信を行う。
【００２８】
フローＳ１００１において配信する情報があると判断した場合は、フローＳ１００２において、予め登録されている配信先機器に対してユニキャストでＳＳＬネゴシエーション開始パケットを送信する。フローＳ１００３において、リプライパケットからネゴシエーションが成功したか失敗したかを判別し、成功の場合は従来技術と同様にフローＳ１００４において送信情報データを暗号化して送信先機器に対して送信する。
【００２９】
フローＳ１００３において、ネゴシエーションが失敗した場合は、フローＳ１００７において命令コマンドを配信先機器に対して送信する。その後はフローＳ１００８においてＳＳＬネゴシエーション開始パケットが来るのを待つ。ＳＳＬネゴシエーションパケットが受信できなかった場合は、処理を終了する。一方、ネゴシエーションパケットを受信した場合は、受信完了のリプライを行いネゴシエーションを完了させセキュア通信路を確立する。
【００３０】
次にフローＳ１０１０において、ＳＳＬで暗号化された情報リクエストパケットが受信するのを待つ。パケットの受信がない場合はそのまま処理を終了する。また、パケット受信した場合は、フローＳ１０１１において共通鍵を使用してパケットデータを復号化し、要求されているリクエスト識別子を解釈し、該当する設定値を記憶装置から抽出する。次にフローＳ１０１２において、パケットデータを暗号化して配信先機器に送信する。この処理をリクエストデータがなくなるまで繰り返す。
【００３１】
一方、図１２には配信先機器の処理のフローチャートを示す。
【００３２】
まずフローＳ２００１において配信元機器からＳＳＬネゴシエーションの要求を受信した場合、自身にＳＳＬサーバの設定がされているかどうかを判断する。具体的には鍵と証明書が予め作成されているかどうかを判断する。このとき、設定がされていた場合は、従来技術と同様に、フローＳ２００３においてネゴシエーションに対して正常リプライを送信しＳＳＬ通信路を確立する。そしてフローＳ２００４以降で配信元機器から送付される情報がなくなるまで受信を繰り返し、受信した情報を自身の設定に反映させる。
【００３３】
一方、フローＳ２００２において自身のＳＳＬサーバが設定されていない場合は、フローＳ２００７においてネゴシエーション拒否のパケットを送信する。この後配信元機器が本発明の機能を有していれば、フローＳ２００８において命令コマンドが送信され、配信先機器はこの命令コマンドを受信する。フローＳ２００９において、命令コマンドを受信した配信先機器は、配信元機器に対してＳＳＬネゴシエーション開始要求パケットを送信する。この要求に対してネゴシエーション拒否のリプライがあった場合は処理を終了する。一方ネゴシエーション完了の通知があった場合は、フローＳ２０１１において命令コマンドで格納されている識別子を格納して、情報リクエストデータを作成し、共通鍵で暗号化を行う。フローＳ２０１２においてリクエストパケットを送信した後、フローＳ２０１３において受信データを待つ。リプライパケットを受信したら、フローＳ２０１４においてデータを復号化し、要求した識別子に対応した値を抽出し、その設定値を自身の機器に反映させる。フローＳ２０１３において受信データがまだある場合は、データ終了までこの処理を繰り返す。
【実施例２】
【００３４】
本章では、実施例１で説明した配信元と配信先がやり取りするパケットフォーマットを改変し、より柔軟でトラフィックを軽減できる実施例について説明する。
【００３５】
図１３は、配信元機器が送信する命令コマンドのパケットフォーマットの改変例である。コマンド種別の領域には図６と同様の値が格納されるが、データ領域には、配信ＩＤのみを格納する。このパケットフォーマットを受信した配信先機器は図１４のリクエストパケットフォーマットに従って、情報要求を行う。データの領域の配信ＩＤは前記命令コマンドで指定された配信ＩＤと同じ値を格納しておく。
【００３６】
前記リクエストパケットを受信した配信元機器は、図１５で示すような管理テーブル表に従って、配信ＩＤに対応した識別子と識別子情報を図９のパケットフォーマットで返信する。
【００３７】
この実施例の場合では、配信元機器がどの配信先にどの情報を配信するべきかを全て図１５の管理テーブル表で管理を行っているため、実施例１のように配信先機器に情報識別子を意識させる必要はなく、配信先機器の負荷とトラフィックの軽減につながる。
【００３８】
配信元機器は、命令コマンドを配信先機器に対して送信する際、どの配信先に対してどの配信ＩＤを割り振ったかを管理テーブル表に書き込みをすることによって記憶しておく。
【実施例３】
【００３９】
前記実施例では、配信元機器は常にＳＳＬが有効になっているウェブサーバとして動作している必要がある。しかし、配信先機器がＳＳＬクライアントにならない限りウェブサーバとして機能は不要になるため、無駄なポートを開いてセキュリティ上の危惧がある。
【００４０】
そのため、本実施例では、図５のフローＳ２０３において配信元機器が配信先機器に対して命令コマンドを送信した時点で初めてＳＳＬおよびＨＴＴＰポートを開くような制御処理を行う。そして、図５の一連のシーケンスが終了し、情報をセキュアに配信することが完了したら配信元機器にウェブアクセスしてくる機器はいないはずなので、再びＳＳＬおよびＨＴＴＰポートを閉じる。この処理によって、必要な時にしかポートを開閉しないので、配信元機器のセキュリティを向上することができる。
【特許請求の範囲】
【請求項１】
通信回線を介して、外部機器との情報の送受信を行うことができるネットワークデバイスにおいて、
前記外部機器との情報の送受信を行うネットワークプロトコルスタックを搭載し、ネットワークデータのパケットをやり取りする送受信手段と、
情報をウェブサービスのパケット形式で送受信する送受信手段と、
前記パケットを暗号化復号化する暗号処理手段と、
前記暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段と、
前記ネゴシエーションに失敗した場合、通信相手先に暗号通信を確立させる命令を送信する送信手段と、
前記命令を受信した場合に、通信相手先に対して暗号通信を確立するためのネゴシエーションを行う制御手段を有するネットワークデバイスから構成されることを特徴とするネットワークデバイス。
【請求項２】
請求項１に記載のネットワークデバイスにおいて、情報とは識別子によって管理され、前記識別子はそれぞれの識別子に対応するデータフォーマットを有するような識別子であることを特徴とするネットワークデバイス。
【請求項３】
請求項１、又は請求項２に記載のネットワークデバイスにおいて、
前記識別子に基づいて情報を要求する要求手段と、前記識別子を要求されたら該当する識別子の情報を提供する提供手段を有することを特徴とするネットワークデバイス。
【請求項４】
請求項１に記載のネットワークデバイスにおいて、
ウェブサービスとはＨＴＴＰプロトコル上で動作するようなプロトコルを制御する制御手段を有することを特徴とするネットワークデバイス。
【請求項５】
請求項１に記載のネットワークデバイスにおいて、
暗号処理手段とはＳＳＬやＴＬＳであり、ＨＴＴＰ上で動作するようなプロトコルを制御する制御手段を有することを特徴とするネットワークデバイス。
【請求項６】
請求項１に記載のネットワークデバイスにおいて、
通信相手先に暗号通信を確立させる命令には、前記識別子情報あるいは配信先情報であり、一意に特定できる情報を含んでいる命令を有することを特徴とするネットワークデバイス。
【請求項７】
請求項１に記載のネットワークデバイスにおいて、
通信相手先に暗号通信を確立させる命令を送信した後にはじめて通信に必要なポートを開閉するような制御手段を有することを特徴とするネットワークデバイス。
【請求項１】
通信回線を介して、外部機器との情報の送受信を行うことができるネットワークデバイスにおいて、
前記外部機器との情報の送受信を行うネットワークプロトコルスタックを搭載し、ネットワークデータのパケットをやり取りする送受信手段と、
情報をウェブサービスのパケット形式で送受信する送受信手段と、
前記パケットを暗号化復号化する暗号処理手段と、
前記暗号通信を確立するために通信相手先とネゴシエーションを行う制御手段と、
前記ネゴシエーションに失敗した場合、通信相手先に暗号通信を確立させる命令を送信する送信手段と、
前記命令を受信した場合に、通信相手先に対して暗号通信を確立するためのネゴシエーションを行う制御手段を有するネットワークデバイスから構成されることを特徴とするネットワークデバイス。
【請求項２】
請求項１に記載のネットワークデバイスにおいて、情報とは識別子によって管理され、前記識別子はそれぞれの識別子に対応するデータフォーマットを有するような識別子であることを特徴とするネットワークデバイス。
【請求項３】
請求項１、又は請求項２に記載のネットワークデバイスにおいて、
前記識別子に基づいて情報を要求する要求手段と、前記識別子を要求されたら該当する識別子の情報を提供する提供手段を有することを特徴とするネットワークデバイス。
【請求項４】
請求項１に記載のネットワークデバイスにおいて、
ウェブサービスとはＨＴＴＰプロトコル上で動作するようなプロトコルを制御する制御手段を有することを特徴とするネットワークデバイス。
【請求項５】
請求項１に記載のネットワークデバイスにおいて、
暗号処理手段とはＳＳＬやＴＬＳであり、ＨＴＴＰ上で動作するようなプロトコルを制御する制御手段を有することを特徴とするネットワークデバイス。
【請求項６】
請求項１に記載のネットワークデバイスにおいて、
通信相手先に暗号通信を確立させる命令には、前記識別子情報あるいは配信先情報であり、一意に特定できる情報を含んでいる命令を有することを特徴とするネットワークデバイス。
【請求項７】
請求項１に記載のネットワークデバイスにおいて、
通信相手先に暗号通信を確立させる命令を送信した後にはじめて通信に必要なポートを開閉するような制御手段を有することを特徴とするネットワークデバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−２０００９８（Ｐ２０１０−２０００９８Ａ）
【公開日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願番号】特願２００９−４３９２３（Ｐ２００９−４３９２３）
【出願日】平成２１年２月２６日（２００９．２．２６）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願日】平成２１年２月２６日（２００９．２．２６）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]