JP2004254286A - 通信装置、通信システムおよびアルゴリズム選択方法 - Google Patents
通信装置、通信システムおよびアルゴリズム選択方法 Download PDFInfo
- Publication number
- JP2004254286A JP2004254286A JP2003367891A JP2003367891A JP2004254286A JP 2004254286 A JP2004254286 A JP 2004254286A JP 2003367891 A JP2003367891 A JP 2003367891A JP 2003367891 A JP2003367891 A JP 2003367891A JP 2004254286 A JP2004254286 A JP 2004254286A
- Authority
- JP
- Japan
- Prior art keywords
- encryption
- communication
- algorithm
- communication device
- cryptographic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【課題】 暗号処理と他の高負荷な処理を同時に行なう場合においても、両方の処理をリアルタイムに正常に行なえるようにする。
【解決手段】 通信装置２４内の暗号情報決定部３２は、通信相手であるネットワークカメラ１２内の暗号情報決定部１８と、暗号通信に利用する暗号アルゴリズムを折衝する。この時、通信装置２４のＣＰＵ負荷に応じて、選択する暗号アルゴリズムを変化させる。すなわち、ＣＰＵ使用率が高い場合には低負荷の暗号アルゴリズムを選択し、ＣＰＵ使用率が低い場合には高負荷の暗号アルゴリズムを選択する。暗号処理部３８は、暗号情報決定部３２が選択した暗号アルゴリズムを用いて暗号処理を行なう。
【選択図】 図１
【解決手段】 通信装置２４内の暗号情報決定部３２は、通信相手であるネットワークカメラ１２内の暗号情報決定部１８と、暗号通信に利用する暗号アルゴリズムを折衝する。この時、通信装置２４のＣＰＵ負荷に応じて、選択する暗号アルゴリズムを変化させる。すなわち、ＣＰＵ使用率が高い場合には低負荷の暗号アルゴリズムを選択し、ＣＰＵ使用率が低い場合には高負荷の暗号アルゴリズムを選択する。暗号処理部３８は、暗号情報決定部３２が選択した暗号アルゴリズムを用いて暗号処理を行なう。
【選択図】 図１
Description
本発明は、通信装置、通信システムおよびアルゴリズム選択方法に関し、より特定的には、暗号通信などのデータの通信を行なう際に使用する暗号アルゴリズムなどの選択に関する。
＜ネット家電＞
近年のインターネット技術の普及に伴い、携帯端末や家電製品などをインターネットに接続し、さまざまなサービスを展開しようという動きが活発になっている。インターネットに接続可能な家電製品のさきがけとして、現在ｅｐステーションのような通信装置が発売されている。そのｅｐステーションは、図４２で示されるようなｅｐサービスを実現するための機器である。ｅｐサービスの特徴は次の２つである。まず、放送局とｅｐステーションをインターネットで結ぶことにより、放送と通信を融合したサービス、例えばＴＶショッピングや視聴者参加型番組などを実現することができる。また、ｅｐステーションはハードディスクを備えるため、衛星から放送されたＴＶ番組や広告データ、インターネットからから受信した電子メールデータなどを蓄積することができる。
近年のインターネット技術の普及に伴い、携帯端末や家電製品などをインターネットに接続し、さまざまなサービスを展開しようという動きが活発になっている。インターネットに接続可能な家電製品のさきがけとして、現在ｅｐステーションのような通信装置が発売されている。そのｅｐステーションは、図４２で示されるようなｅｐサービスを実現するための機器である。ｅｐサービスの特徴は次の２つである。まず、放送局とｅｐステーションをインターネットで結ぶことにより、放送と通信を融合したサービス、例えばＴＶショッピングや視聴者参加型番組などを実現することができる。また、ｅｐステーションはハードディスクを備えるため、衛星から放送されたＴＶ番組や広告データ、インターネットからから受信した電子メールデータなどを蓄積することができる。
現在のｅｐステーションでは、電話回線を用いてインターネットに接続している。しかし、ＡＤＳＬやＣＡＴＶ、光ファイバーなどの高速回線の普及によって、家庭においても高速なインターネット接続環境が整いつつあり、今後高速通信が可能なｅｐステーションの後継機が登場することは容易に想像できる。
非特許文献１では、ｅｐサービスの前身であるｅプロットフォーム構想について述べられており、高画質放送とデータ放送、蓄積放送サービスやインターネットへの高速アクセスを連動させたサービスの形態が示されている。高速インターネットを利用したアプリケーションとしては、映像配信や音楽配信などのダウンロードサービス、テレビ電話やネットワークカメラによる監視などが考えられる。
これらの応用用途の中でネットワークカメラを利用する場合を考える。ネットワークカメラの民生用の利用法としては、保育所にいる子供の様子や、独居老人となっている親の様子、外出中の自宅の様子などを観察するなどが考えられる。このようなプライバシーを伴うような映像をインターネット上で盗み見られないようにするためには、映像データを暗号化などにより保護する必要がある。
暗号通信を必要とするものとしては、上記のようなプライベートなデータの送信、電子商取引に関するデータの送受信、インターネットサービスなどでＩＳＰから各顧客のシステムに対して行なう機器制御情報の伝送、携帯電話などの個人端末から自宅の端末装置に留守の間に行なう操作情報の伝送（たとえば風呂を沸かしたりエアコンをＯＮにしたり）など、様々な用途がある。
＜暗号通信＞
従来から、機密性が必要とされるデータをインターネットなどの公衆ネットワーク上でやりとりする場合には、データの暗号化処理が行われている。非特許文献２では、インターネット上に潜む危険と、その対策としての暗号や認証の技術について詳しく述べられている。また、非特許文献３等には、インターネットで用いられている代表的な暗号化・認証プロトコルであるＩＰｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）について詳細に述べられている。
従来から、機密性が必要とされるデータをインターネットなどの公衆ネットワーク上でやりとりする場合には、データの暗号化処理が行われている。非特許文献２では、インターネット上に潜む危険と、その対策としての暗号や認証の技術について詳しく述べられている。また、非特許文献３等には、インターネットで用いられている代表的な暗号化・認証プロトコルであるＩＰｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）について詳細に述べられている。
以下では、暗号通信の一般的な処理の流れを説明する。まず、データ送信側とデータ受信側の双方において、同じ暗号アルゴリズムを設定する。また、双方において、暗号化鍵と通信相手が暗号化したデータを復号化するための復号化鍵を設定する。暗号化鍵と復号化鍵が同じ場合は、共有鍵とも呼ばれる。なお、暗号アルゴリズムや鍵の設定は手動で設定するか、もしくは双方間の自動ネゴシエーションによって行われる。以上の設定が完了すると、次のような手順で暗号通信が行われる。まず、データ送信側は、送信データを設定された暗号アルゴリズムと暗号化鍵を用いて暗号化し、インターネット回線網に送信する。受信側は、暗号化されたパケットを受信すると、設定された暗号アルゴリズムと復号化鍵を用いて、暗号化パケットを復号化する。
図４３は、保育園に設置したネットワークカメラと家庭内のデジタルテレビをインターネット回線網で接続し、保育園での子供の状況を母親が家庭内で見ることができるようにしたシステムを想定した場合の、暗号通信に関する部分を説明するブロック図である。
この場合、暗号処理部２１８は、デジタルテレビ自身の通信処理部２１６、インターネット回線網および相手のネットワークカメラの通信処理部２０６を介して、ネットワークカメラの暗号処理部２０４との間で各種データをパケット形式にして通信を行なう。まず、データ送信側とデータ受信側が同じ暗号アルゴリズムを使用するために、双方の間で、上記のネゴシエーションが行われる。暗号アルゴリズムのネゴシエーションにおいては、ネゴシエーション用のパケットを相手との間でやり取りする。まず、デジタルテレビの暗号情報決定部２１４は、送信用のネゴシエーションパケットを所定の形式で作成して、使用する暗号アルゴリズムをネットワークカメラに提案する。ネットワークカメラでは、通信処理部２０６および暗号処理部２０４を経由して得た提案暗号アルゴリズムを暗号・復号情報として暗号情報決定部２０２に渡し、提案された暗号アルゴリズムが使用可能かどうかを暗号情報決定部２０２で判定する。そして、使用の可否を、暗号処理部２０４および通信処理部２０６を経由して回答する。デジタルテレビの暗号情報決定部２１４は、その回答を通信処理部２１６および暗号処理部２１８を経由して受信し、受信した回答が「使用可能」であれば、提案した使用可能な暗号アルゴリズムを確定することをネゴシエーションパケットとしてネットワークカメラに通知して、使用する暗号アルゴリズムのネゴシエーションを終了する。また、暗号情報決定部２１４は、決定した暗号アルゴリズムを暗号処理部２１８に知らせて、アルゴリズム設定を指示する。また、暗号情報決定部２０２の方も、決定した暗号アルゴリズムを暗号処理部２０４に知らせて、アルゴリズム設定を指示する。その次に、暗号情報決定部２１４、２０２、暗号処理部２１８、２０４は、お互いに所定の通信を行ない、設定した暗号アルゴリズムに従って決められた手順により、決められた形態の暗号化鍵や復号化鍵を作成、設定する。暗号化鍵や復号化鍵が生成されると、以降は、暗号通信が可能になる。撮影部（図示しない）が撮影した映像データを、暗号通信アプリケーション２００が、暗号処理部２０４に渡す。暗号処理部２０４は、設定された暗号アルゴリズムを使用して映像データを暗号化し、データパケット化して、通信処理部２０６およびインターネット回線網を経て、デジタルテレビに送る。デジタルテレビでは、そのデータパケットを通信処理部２１６で受信した後、暗号処理部２１８において復号化し、復号化された映像データを暗号通信アプリケーション２１０に渡す。暗号通信アプリケーション２１０は、ネットワークカメラの映像データをテレビのディスプレイの所定位置に所定の大きさで表示する処理を行なう。
このような従来のネゴシエーションでは、暗号情報決定部２１４は、暗号アルゴリズムの提案を行なう場合には、保有している暗号アルゴリズムから、ユーザによって設定された、又はプログラム中であらかじめ定められている、ひとつまたは複数の暗号アルゴリズムを選んで相手に提案する。また、相手から提案を受けた場合は、その提案に対する応答として、保有している暗号アルゴリズムの中で最も高優先度の暗号アルゴリズムを選択して通知するようにしている。
ところで、暗号通信アプリケーション２１０、２１２のように暗号アルゴリズムを用いて暗号化・復号化を行なう必要のあるアプリケーションが複数あり、複数種のデータを並行して暗号化・復号化処理を行なう場合、両方とも暗号強度の高いアルゴリズムを採用すると、暗号アルゴリズムは一般的に大きなＣＰＵ処理能力を必要とするため、複数の暗号通信アプリケーションの処理およびそれらのための複数の暗号処理にかかる全負荷がＣＰＵ処理能力を超えてしまい、システムが破綻する。このような事態を防止するために、特許文献１では、通信データを複数のブロックに分割し、重要度の高いデータが格納されたブロックに対して暗号強度が高い暗号アルゴリズムを使う一方、重要度の低いデータが格納されたブロックに対しては暗号強度が低い暗号アルゴリズムを使うことにより、必要なＣＰＵ処理資源量を逓減するようにしている。
野村敦子著、「ブロードバンド革命−目指せ！ユビキタス・ネットワーク社会」、初版、中央経済社、平成１３年４月１日、ｐ．２２５−２２７（ＩＳＢＮ４−５０２−５７２１１−Ｘ） ユーリス・ブラック著、波多浩昭、松本直人訳、「インターネットセキュリティガイド」、初版、ピアソン・エデュケーション発行、２００１年１１月２０日、全頁（ＩＳＢＮ４−８９４７１−４５５−８） 「ＲＦＣ２４０１」、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）発行 特開２００２−１９０７９８号公報（第６頁、第６図）
野村敦子著、「ブロードバンド革命−目指せ！ユビキタス・ネットワーク社会」、初版、中央経済社、平成１３年４月１日、ｐ．２２５−２２７（ＩＳＢＮ４−５０２−５７２１１−Ｘ） ユーリス・ブラック著、波多浩昭、松本直人訳、「インターネットセキュリティガイド」、初版、ピアソン・エデュケーション発行、２００１年１１月２０日、全頁（ＩＳＢＮ４−８９４７１−４５５−８） 「ＲＦＣ２４０１」、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）発行
上述したように、暗号通信で行われる暗号処理では、送受信データに対して複雑な処理を行なう必要がある。このため、暗号通信は、暗号化を行なわない通信に比べて処理負荷が非常に高い。たとえば、ネットワークカメラデータの復号化処理（暗号通信アプリケーション２１０）と、テレビ放送の映像データの録画（アプリケーション２０８）という、リアルタイムに処理しなければならない高負荷な処理が重なった場合、前述のようなネゴシエーションでは、より暗号強度が高い暗号アルゴリズムを選択するので、内蔵ＣＰＵの処理能力では両方を同時には処理しきれない可能性がある。つまり、ＴＶ放送の録画に失敗するか、もしくは、ネットワークカメラの画像が乱れたり止まったりするという問題が発生することがある。図４４は、このときの内蔵ＣＰＵの処理能力と、ネットワークカメラ画像の受信・表示に必要なＣＰＵリソースおよびＴＶ録画に必要なＣＰＵリソースの関係を表している。つまり、図４４のようにネットワークカメラ画像の受信・表示に必要なＣＰＵリソースと、ＴＶ録画に必要なＣＰＵリソースの合計が、内蔵ＣＰＵの処理能力を越えた場合に、上記のような問題が発生する。
それゆえに、本発明の目的は、暗号通信処理と他の高負荷な処理を同時に行なわなければならない場合に、できるだけ強固な機密性を提供しつつも暗号処理の負荷を軽減し、ＣＰＵリソースの枯渇によって生じる上記のような問題を解決することである。
本発明の第１の通信装置は、予め用意された複数の暗号アルゴリズムの中から、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択する暗号情報決定部と、暗号情報決定部が選択した暗号アルゴリズムにしたがってパケットを暗号化する暗号処理部と、暗号処理部が暗号化したパケットを送信する通信処理部とを備えた通信装置である。
本発明の第２の通信装置は、予め用意された複数の暗号アルゴリズムの中から、通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択する暗号情報決定部と、暗号情報決定部が選択した暗号アルゴリズムにしたがって通信相手宛てのパケットを暗号化する暗号処理部と、暗号処理部が暗号化したパケットを送信する通信処理部とを備えた通信装置である。
上記第１の通信装置によれば、資源の不足によって通信装置側の処理に支障が出ることを防ぐことができる。
上記第２の通信装置によれば、資源の不足によって通信相手側の処理に支障が出ることを防ぐことができる。
以下、本発明の種々の実施の形態を、図面を参照して説明する。
（実施の形態１）
図１は、本発明の実施の形態１に関わるシステムの構成図である。図１において、実施の形態１のシステムは、放送設備１０と、通信装置２４と、ネットワークカメラ１２と、インターネット２２と、ディスプレイ（映像表示装置）４０とから構成される。
図１は、本発明の実施の形態１に関わるシステムの構成図である。図１において、実施の形態１のシステムは、放送設備１０と、通信装置２４と、ネットワークカメラ１２と、インターネット２２と、ディスプレイ（映像表示装置）４０とから構成される。
次に、ネットワークカメラ１２および通信装置２４の持つ機能を詳細に述べる。ネットワークカメラ１２は、撮影部１４と、暗号処理部１６と、暗号情報決定部１８と、通信処理部２０とを具備する。なお、撮影部１４と暗号処理部１６の間に、図４３に示したような暗号通信アプリケーション２００を具備していてもよい。
また、通信装置２４は、通信機能と録画機能を有する家電機器であって、受像部２６と、録画アプリケーション２８と、リソース監視部３０と、暗号情報決定部３２と、通信処理部３６と、暗号処理部３８と、ネットワークカメラアプリケーション３４とを具備する。なお、図１において破線で囲んだ構成部分、すなわち録画アプリケーション２８、リソース監視部３０、暗号情報決定部３２、通信処理部３６、暗号処理部３８、ネットワークカメラアプリケーション３４は、内蔵ＣＰＵがソフトウェアを実行することにより実現される。なお、本発明のアルゴリズム選択方法は、本実施の形態においては通信装置２４内の暗号情報決定部３２において用いられるものとして説明する。
次に、本システムの動作について説明する。
まず、ＴＶ録画を行なう際のシステムの動作について説明する。受像部２６は放送設備１０が放送しているＴＶ放送データを受信する。続いて、受信されたＴＶ放送データを、録画アプリケーション２８が、通信装置２４内蔵の蓄積媒体に記録する。この処理は内蔵のＣＰＵを利用して行われる。以上の処理を、録画したいＴＶ番組の放送開始時刻から放送終了時刻まで連続的に行なうことで、ＴＶ録画が完了する。
次に、ネットワークカメラ１２の映像をディスプレイ４０に表示する際のシステムの動作について説明する。この処理は、暗号通信を行なうための事前処理と、実際にネットワークカメラアプリケーション３４を動作させる処理の２つに分かれる。暗号通信を行なうための事前処理については後述し、はじめに、実際にネットワークカメラアプリケーション３４を動作させる処理の概要について述べる。まず、ネットワークカメラ１２では、撮影部１４が撮影した映像データを、暗号処理部１６が暗号化する。通信処理部２０は、その暗号化された映像データを通信装置２４宛のパケットとしてインターネット２２に送出する。通信装置２４では、通信処理部３６でインターネット２２から暗号化パケットを受信し、暗号処理部３８で復号化し、ネットワークカメラアプリケーション３４は、復号化された映像データをディスプレイ４０に出力する。そして、ディスプレイ４０が映像を表示する。以上のようにして、ネットワークカメラ１２で撮影された映像がディスプレイ４０に表示される。
次に、暗号通信を行なうための事前処理について説明する。ここでいう事前処理とは、ネットワークカメラ１２内の暗号情報決定部１８と、通信装置２４内の暗号情報決定部３２との間で、暗号通信に利用する暗号アルゴリズムおよび暗号化鍵、復号化鍵としてどのようなものを使用するかを折衝し、それぞれの暗号処理部１６、３８に設定する処理である。以下、通信装置２４の内蔵ＣＰＵによって行われるべき処理の負荷が図４４に示したように内蔵ＣＰＵの処理能力を超えてしまう事態を防止するための折衝について説明する。
図２は、通信装置２４の、ネゴシエーションに関わる構成部分を示すブロック図である。データ送信側とデータ受信側が同じ暗号アルゴリズムを使用するために、双方の間でネゴシエーションが行われる。通信処理部３６は、相手の通信処理部との間でデータパケットの通信を行なう。暗号アルゴリズムのネゴシエーションにおいては、ネゴシエーション用のパケットを相手との間でやり取りする。ネゴシエーションパケット作成・解釈部４８は、送信時には、暗号アルゴリズム選択部４２の指示に基づき、送信用のネゴシエーションパケットを所定の形式で作成し、受信時には、受信したネゴシエーションパケットの内容を解釈して暗号アルゴリズム選択部４２に入手情報を渡す。暗号アルゴリズム選択部４２は、決定した暗号アルゴリズムを暗号アルゴリズム設定部５０に知らせて、アルゴリズム設定を指示する。暗号処理部３８は、設定された暗号アルゴリズムを使用してデータの暗号化や復号化を行なう。暗号アルゴリズム選択部４２は、リソース監視部３０からあらかじめあるいはネゴシエーション時に入手したＣＰＵ使用率情報を格納するためのＣＰＵ使用率情報メモリ４４を有している。本実施の形態では、暗号アルゴリズム選択部４２は、暗号処理使用資源表４６や、リソース監視部３０から得たＣＰＵ使用率情報を参照しながら、暗号アルゴリズムの提案処理や選択処理を行なう。暗号処理使用資源表４６については、後述する。
なお、本実施の形態では、暗号情報決定部３２がネゴシエーションパケットを生成してこれを暗号化した後、通信処理部３６を通じてこの暗号化されたネゴシエーションパケットを送信するが、他の形態でも構わない。例えば、暗号情報決定部３２がネゴシエーションパケットを生成し、暗号処理部３８がそのネゴシエーションパケットを暗号化した後、この暗号化されたネゴシエーションパケットが通信処理部３６を通じて送信されてもよい。また、例えば、暗号情報決定部３２がネゴシエーションパケットを生成し、暗号処理部３８がそのネゴシエーションパケットを暗号化した後、この暗号化されたネゴシエーションパケットをいったん暗号情報決定部３２に返し、暗号情報決定部３２が通信処理部３６を通じてこの暗号化されたネゴシエーションパケットを送信してもよい。
ここで、ＣＰＵ使用率について説明する。ＣＰＵ使用率は、ＣＰＵの最大処理能力を１００％とした場合、録画アプリケーション２８やネットワークカメラアプリケーション３４などの個々のアプリケーションが使用するＣＰＵ処理能力を％で表したものである。ＣＰＵの処理方式には種々の方式が存在するが、最も一般的なものは、ある時刻にタスクを一つだけ処理する方式である。複数のタスクを処理する場合は、それらのタスクを時分割で処理することにより、同時並行して処理しているように見せている。軽いタスクには短い時間を、重いタスクには長い時間を割り当てる方法がある。また、時間を一定の短い処理時間単位（タイムスロット、スレッドなどと呼ぶ。）で区切り、重いタスクには軽いタスクよりも頻繁に単位時間を割り当てるようにする方法もある。ＣＰＵリソースに余裕があり、ＣＰＵがモニタプログラムなどの共通的処理以外のタスクを処理していない時間や処理時間単位は、アイドル状態として検出される。このようなＣＰＵ方式において、タスクのＣＰＵ使用率を計測するには以下のようにすればよい。ＣＰＵのＯＳ内のモニタプログラムなどを使用して、比較的短時間毎に、処理しているタスクが何であるかをサンプリングして調べさせる。アプリケーションＡがタスクＡにより構成されている場合を考える。１０００回調べた結果、５００回がタスクＡで、残りの５００回はＣＰＵが待機状態、すなわちアイドル状態であったとする。この場合は、アプリケーションＡのＣＰＵ使用率は５０％である。ＣＰＵは、ＯＳのモニタプログラムなどの共通的カーネル処理を行なうが、この処理は全体から見ると少ないので、一応ここでは無視することとする。
サンプル数はある程度多くして、その時刻の瞬間ＣＰＵ使用率ではなく、ある程度平滑化されたＣＰＵ使用率、例えばその時刻までの一定時間の平均ＣＰＵ使用率を計測して用いるのが好ましい。瞬間あるいは短時間のＣＰＵ使用率は一時的に大きく変動するので、アプリケーションが必要とするＣＰＵ処理能力を算出するのには適さない。
アプリケーションＡの処理が２つの部分に別れていて、タスクＡとカーネル処理とにより実行される場合に、タスクＡが５００回、カーネル処理が１００回、アイドル状態が４００回と計測された場合は、アプリケーションＡのＣＰＵ使用率は６０％となる。また、タスクＡは５０％、カーネル部分は１０％と計測できる。つぎに、アプリケーションＡとアプリケーションＢの２つの処理プログラムが並行して実行される場合について説明する。アプリケーションＢもその一部がカーネルにおいて処理されるものとする。カーネルにおいてはアプリケーションＡとアプリケーションＢの各一部が処理されるが、カーネル全体のＣＰＵ使用率しか計測できないことが多い。すなわち、カーネルの中でどのようなアプリケーションが処理されているのか、また共通カーネル処理が実行されているのか、などは区別できないことが多い。従って、このケースでは、アプリケーションＡとアプリケーションＢのＣＰＵ使用率の合計値は、１００％からアイドル処理のＣＰＵ使用率を差し引いたものとして計測できるものの、アプリケーションＡとアプリケーションＢの個々のＣＰＵ使用率は計測できない。なぜなら、カーネル処理の内のアプリケーションＡとアプリケーションＢの内訳が計測できないからである。もしも、アプリケーションＡのみが実行されているときに、上記のように、アプリケーションＡが６０％、タスクＡが５０％、カーネル部分が１０％と計測できていれば、引き算により、アプリケーションＢ、タスクＢ、カーネルのアプリケーションＢ部分を算出できる。
つぎに、暗号アルゴリズムネゴシエーション処理について以下で詳細に述べる。以下では、ネットワークカメラ１２内の暗号情報決定部１８と、通信装置２４内の暗号情報決定部３２のうち、ネゴシエーションを開始する側をイニシエータと呼び、イニシエータに対して応答する側をレスポンダと呼ぶ。
図３は、暗号アルゴリズムネゴシエーション処理のシーケンスを表している。図３で、まずイニシエータが、複数の暗号アルゴリズム（ここでは仮に暗号アルゴリズムａ、ｂ、ｃとする）の情報を含んだ提案パケットをレスポンダに対して送信する。レスポンダは、その提案パケットを受信すると、その中からひとつの暗号アルゴリズム（ここでは仮に暗号アルゴリズムｂとする）を選択し、イニシエータに対して、選択した暗号アルゴリズムの情報を含んだ応答パケットを送信する。イニシエータは、レスポンダからの応答パケットを受信すると、そこに含まれている暗号アルゴリズム（暗号アルゴリズムｂ）を採用する。以上のようにして、イニシエータとレスポンダの両方で同じ暗号アルゴリズム（暗号アルゴリズムｂ）を使うことが約束され、暗号通信を行なえるようになる。
なお、イニシエータが提案する暗号アルゴリズムは１つでもよい。また、レスポンダは、提案された暗号アルゴリズムの中に利用可能な暗号アルゴリズムがなければ、応答しなくてもよい。また、通信装置２４内の暗号情報決定部３２が、イニシエータとして暗号アルゴリズムを提案したり、レスポンダとして暗号アルゴリズムを選択する際には、リソース監視部３０から得たＣＰＵ使用率の情報を用いるが、その際の具体的な手順については後述する。
なお、暗号アルゴリズムを折衝する際のメッセージのやりとりは、図３のシーケンスに限定するものではなく、既存の鍵交換プロトコルの規定に則って行っても良い。例えば、一般的にＩＰｓｅｃと併用されることが多い鍵交換プロトコルＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）を使って、規定のメッセージシーケンスの中で暗号アルゴリズムを折衝しても良い。
また、ここでは暗号アルゴリズムのネゴシエーションを、暗号通信を行なう前に一度だけ行なう例について説明したが、暗号通信の途中において暗号アルゴリズムをネゴシエーションし直してもよい。
次に、通信装置２４内の暗号情報決定部３２が、イニシエータとして、レスポンダに対して提案する暗号アルゴリズムを決定する手順や、レスポンダとして、イニシエータから提案された複数の暗号アルゴリズムの中からイニシエータに応答通知する暗号アルゴリズムを選択する手順について説明する。ところで、暗号アルゴリズムにはさまざまなものがあるが、それぞれによって暗号化復号化処理の負荷や、暗号の破られにくさを示す暗号強度が異なる。したがって、本実施の形態では、基本的には、ネットワークカメラ映像の暗号化に用いる暗号アルゴリズムとして、ＣＰＵに余裕のある場合にはできるだけ暗号強度の高いものを選択してセキュリティを高め、ＣＰＵに余裕のない場合にはＣＰＵリソースが不足しないように処理負荷の低いものを選択する。
＜通信装置２４がレスポンダとなる場合＞
さて、図４および図５は、通信装置２４内の暗号情報決定部３２がレスポンダとなる場合のフローチャートである。以下では、まず図４のフローチャートに沿って説明を行なう。
さて、図４および図５は、通信装置２４内の暗号情報決定部３２がレスポンダとなる場合のフローチャートである。以下では、まず図４のフローチャートに沿って説明を行なう。
まず、通信装置２４内の暗号情報決定部３２（以下レスポンダ）は、暗号処理部３８がサポートしている暗号アルゴリズムの集合Ａを求める（Ｓ４０１）。ここで、ネットワークカメラ１２内の暗号情報決定部１８（以下イニシエータ）からの提案パケットを待つ状態になる。
イニシエータは、まずネゴシエーションの開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。イニシエータは、ネゴシエーション開始要求を受けると（Ｓ４１１）、ネゴシエーションを開始する。すなわち、１つもしくは複数の暗号アルゴリズムの提案を含むパケットをレスポンダに送信する（Ｓ４１２）。この提案パケットを受信したレスポンダでは、提案された暗号アルゴリズムの集合Ｂをパケットから読み取る（Ｓ４０２）。応答可能な暗号アルゴリズム（集合Ｃ）は、提案された暗号アルゴリズム（集合Ｂ）のうち暗号処理部３８がサポートしているもの（集合Ａ）であるので、Ｃ＝Ａ∩Ｂとして求められる（Ｓ４０３）。
さて、ここからレスポンダに対して応答する暗号アルゴリズムを選択するステップに入る（Ｓ５００）。ステップＳ５００の詳細は、図５のフローチャートを用いて説明する。
ここでの前提としては、ＣＰＵを利用するアプリケーションは、録画アプリケーション２８とネットワークカメラアプリケーション３４のみとする。またこの時点では、録画アプリケーション２８だけがすでにＣＰＵを利用しており、ネットワークカメラアプリケーション３４はまだ起動されておらず、ＣＰＵを利用していないものとする。
まず、レスポンダは、リソース監視部３０からＣＰＵ使用率ＣＰＵＵｔｉｌを取得する（Ｓ５０１）。ＣＰＵＵｔｉｌは、その時点で実行されているアプリケーションによるＣＰＵ使用率（アプリケーションが複数の場合はそれらの合計）を表す。ただし、既に述べたように、リソース監視部３０が暗号情報決定部３２に対して通知するＣＰＵ使用率には、その時刻の瞬間ＣＰＵ使用率ではなく、ある程度平滑化されたＣＰＵ使用率（例えばその時刻までの一定時間の平均ＣＰＵ使用率等）を用いる。この理由は、瞬間ＣＰＵ使用率を利用すると、ＣＰＵ使用率の一時的な変動の影響を大きく受けるため、一定時間利用する暗号アルゴリズムを選択する適切な判断基準とはなりえないからである。
次に、応答可能な暗号アルゴリズムの集合Ｃのなかで、以下の式（式１）を満たす暗号アルゴリズムの集合Ｄを求める（Ｓ５０２）。
ＣＰＵＲｅｃｏｒｄ＋ＣＰＵＣａｍｅｒａ（ｘ）≦α ・・・（式１）
ここで、ＣＰＵＲｅｃｏｒｄは録画アプリケーション２８が消費するＣＰＵリソース、ＣＰＵＣａｍｅｒａは暗号アルゴリズムｘを用いて暗号通信を行ったときに、ネットワークカメラアプリケーション３４が必要とするＣＰＵリソースである。したがって、（式１）が満たされるということは、ＴＶ録画と、暗号アルゴリズムｘによる暗号通信を同時に行っても、平均ＣＰＵ使用率がα［％］以下となり、両方のタスクが正常に実行されることを意味している。αの値は、例えば９５％などの値をあらかじめ設定しておく。暗号情報決定部３２は、リソース監視部３０から、複数の暗号アルゴリズムの各々について、暗号処理を行ったときにシステム全体で必要となるＣＰＵリソースを計算するのに必要なＣＰＵ使用率をステップＳ５０１において取得して全処理負荷（ＣＰＵＲｅｃｏｒｄ＋ＣＰＵＣａｍｅｒａ（ｘ））を推定する全処理負荷推定手順をステップＳ５０２において実施している。また、ステップＳ５０２において、（式１）を満たす暗号アルゴリズム（集合Ｄ）を求めるために、各々の暗号アルゴリズムについて、前記全処理負荷と、第１基準値であるαとを比較する比較手順を実施している。
ここで、ＣＰＵＲｅｃｏｒｄは録画アプリケーション２８が消費するＣＰＵリソース、ＣＰＵＣａｍｅｒａは暗号アルゴリズムｘを用いて暗号通信を行ったときに、ネットワークカメラアプリケーション３４が必要とするＣＰＵリソースである。したがって、（式１）が満たされるということは、ＴＶ録画と、暗号アルゴリズムｘによる暗号通信を同時に行っても、平均ＣＰＵ使用率がα［％］以下となり、両方のタスクが正常に実行されることを意味している。αの値は、例えば９５％などの値をあらかじめ設定しておく。暗号情報決定部３２は、リソース監視部３０から、複数の暗号アルゴリズムの各々について、暗号処理を行ったときにシステム全体で必要となるＣＰＵリソースを計算するのに必要なＣＰＵ使用率をステップＳ５０１において取得して全処理負荷（ＣＰＵＲｅｃｏｒｄ＋ＣＰＵＣａｍｅｒａ（ｘ））を推定する全処理負荷推定手順をステップＳ５０２において実施している。また、ステップＳ５０２において、（式１）を満たす暗号アルゴリズム（集合Ｄ）を求めるために、各々の暗号アルゴリズムについて、前記全処理負荷と、第１基準値であるαとを比較する比較手順を実施している。
図６は、集合Ｃの要素が暗号アルゴリズムａ、ｂ、ｃであった場合の例である。この場合、（式１）を満たす暗号アルゴリズム（集合Ｄ）は暗号アルゴリズムｂと暗号アルゴリズムｃである。
ＣＰＵＲｅｃｏｒｄ、ＣＰＵＣａｍｅｒａ（ｘ）の求め方は、先に述べたＣＰＵ使用率の考え方を用いると、以下のとおりとなる。まず、この時点でＣＰＵを利用しているのは録画アプリケーション２８だけであるので、ＣＰＵＲｅｃｏｒｄ＝ＣＰＵＵｔｉｌとなる。また、ＣＰＵＣａｍｅｒａ（ｘ）は、ＣＰＵＣａｍｅｒａ（ｘ）＝ＣＰＵＣａｍｅｒａＣｏｎｓｔ＋ＣＰＵＣａｍｅｒａＥｎｃ（ｘ）として求められる。ここで、ＣＰＵＣａｍｅｒａＣｏｎｓｔは、暗号処理以外の処理でネットワークカメラアプリケーション３４が消費するＣＰＵリソースであり、ＣＰＵＣａｍｅｒａＥｎｃ（ｘ）は暗号アルゴリズムｘを用いたときに、暗号処理で消費するＣＰＵリソースである。
ＣＰＵＣａｍｅｒａＥｎｃ（ｘ）は、アプリケーション層での通信速度に比例すると仮定すると、以下のようにして求められる。ＣＰＵＣａｍｅｒａＥｎｃ（ｘ）＝（ＣａｍｅｒａＲａｔｅ／ＥｎｃＲａｔｅ（ｘ））×１００［％］。ここで、ＣａｍｅｒａＲａｔｅは、ネットワークカメラアプリケーション３４が行なう通信のアプリケーション層での通信速度、ＥｎｃＲａｔｅ（ｘ）は、暗号アルゴリズムｘを利用した暗号通信処理のみに、内蔵のＣＰＵを１００％利用したときのアプリケーション層での通信速度である。
ここで用いたＣＰＵＣａｍｅｒａＣｏｎｓｔ、ＣａｍｅｒａＲａｔｅの値は、計測するのではなく、システムから与えられているものとする。また図７のような暗号処理使用資源表４６を、図２に示したように、暗号情報決定部３２に設けておく。暗号処理使用資源表４６には、各暗号アルゴリズムのＥｎｃＲａｔｅ（ｘ）と共に、それぞれの暗号強度の順位が格納されている。これにより暗号アルゴリズムｘからＥｎｃＲａｔｅ（ｘ）を求めることができる。
なお、ここではネットワークカメラアプリケーション３４がまだ開始されていない場合について説明したが、ネットワークカメラアプリケーション３４が既に開始されており、暗号アルゴリズムとしてｚが用いられていた場合には、ＣＰＵＲｅｃｏｒｄ＝ＣＰＵＵｔｉｌ−ＣＰＵＣａｍｅｒａ（ｚ）のように、録画アプリケーション２８に必要なＣＰＵリソースを求めることができる。また、ＣＰＵＲｅｃｏｒｄの値がシステムから与えられている場合には、その値を用いることもできる。また、ＣＰＵＲｅｃｏｒｄを、以前にこのＣＰＵ上で録画アプリケーション２８のみが実行されていた期間の平均ＣＰＵ使用率としてもよい。また、ＣＰＵＣａｍｅｒａ（ｘ）を、以前にこのＣＰＵ上で暗号アルゴリズムｘを用いたネットワークカメラアプリケーション３４のみが実行されていた期間の平均ＣＰＵ使用率としてもよい。その場合、これらのＣＰＵ使用率情報を、図２のＣＰＵ使用率情報メモリ４４に格納しておく。
なお、ＣＰＵＲｅｃｏｒｄ（％）は、（ＴＶ録画での平均使用ＣＰＵ資源（メガインストラクション／秒：ＭＩＰＳ）／ＣＰＵの能力（ＭＩＰＳ））＊１００（％）と言い換えることができる。また、ＣＰＵＣａｍｅｒａＣｏｎｓｔ（％）は、（カメラアプリケーションでの平均使用ＣＰＵ資源（ＭＩＰＳ）／ＣＰＵの能力（ＭＩＰＳ））＊１００と言い換えることができる。ＣａｍｅｒａＲａｔｅ（Ｍｂｐｓ）は、カメラアプリケーションの平均データ転送量と言い換えることができる。また、ＥｎｃＲａｔｅ（ｘ）（Ｍｂｐｓ）は、最大ＣＰＵ資源（ＭＩＰＳ）／暗号アルゴリズムｘで１Ｍｂｐｓのデータを暗号化するのに必要な平均ＣＰＵ資源（ＭＩＰＳ／Ｍｂｐｓ）と言い換えることができる。
次に、集合Ｄが空集合かどうか、すなわち（式１）を満たす暗号アルゴリズムが存在するかどうかを判定する（Ｓ５０３）。空集合の場合、つまり（式１）を満たす暗号アルゴリズムが存在しない場合は、どの暗号アルゴリズムを用いてもＣＰＵリソースが不足することを示しているため、できるだけＣＰＵ処理負荷を軽減するために、応答可能な暗号アルゴリズム（集合Ｃ）のうち最も処理負荷の低いものを選択する（Ｓ５０５）。
一方、集合Ｄが空集合でない場合は、その中で最も暗号強度の高い暗号アルゴリズムを選択する（Ｓ５０４）。図６の例では、集合Ｄに含まれる暗号アルゴリズムｂ、ｃのうち、暗号強度のより高い暗号アルゴリズムｂが選ばれる。暗号アルゴリズムの処理負荷や暗号強度の情報は、図７の暗号処理使用資源表４６から得ることができる。ステップＳ５０３とステップＳ５０４においては、前記全処理負荷が前記第１基準値を下回る、ひとつもしくは複数の暗号アルゴリズムを選択する選択手順を実施していることになる。
なお、本実施の形態では集合Ｄが空集合の場合に、集合Ｃのうち最も処理負荷の低い暗号アルゴリズムを応答通知するとしたが、この場合にはＣＰＵの処理能力を超えてしまう場合があるので、録画アプリケーション２８を優先する場合には、応答パケットをイニシエータに送信せずに、ネットワークカメラアプリケーション３４を開始しない、もしくは既に開始している場合には中断することもできる。また、カメラ映像を間引いて画質を落として伝送するようにしてもよい。
以降は再び図４を用いて説明する。レスポンダは、ステップＳ５００で選択した暗号アルゴリズムの情報を含む応答パケットをイニシエータに対して送信する（Ｓ４０４）。
次に、レスポンダは、応答通知した暗号アルゴリズムを実際に利用するために、暗号処理部３８にその暗号アルゴリズムを設定する（Ｓ４０５）。一方、イニシエータは、レスポンダからの応答パケットを受信し（Ｓ４１３）、応答通知された暗号アルゴリズムをネットワークカメラ１２内の暗号処理部１６に設定する（Ｓ４１４）。
このあと、ネットワークカメラ１２は、撮影部１４で撮像した映像データを、暗号処理部１６において、設定された暗号アルゴリズムの暗号化機能を使用して暗号化データとし、暗号情報決定部１８に設定された暗号アルゴリズムの識別子、または暗号アルゴリズムと鍵とを特定するセキュリティアソシエーションと呼ばれる情報ＳＡの識別ＩＤを添付する。そして、この暗号化データは、パケットとして通信処理部２０を通じてインターネット２２に送出される。通信装置２４の通信処理部３６は、パケットを受信し、添付された暗号アルゴリズムの識別子、またはＳＡの識別ＩＤをもとに、折衝、合意した暗号アルゴリズムを使用して暗号処理部３８において暗号の復号化を行ない、その結果得られた映像データをディスプレイ４０に表示する。
＜通信装置２４がイニシエータとなる場合＞
次に、通信装置２４内の暗号情報決定部３２がイニシエータとなり、ネットワークカメラ１２内の暗号情報決定部１８とネゴシエーションを行なう場合の手順を示す。また、図８および図９は、このときの動作手順を示すフローチャートである。以下では、まず、図８のフローチャートに沿って説明を行なう。
次に、通信装置２４内の暗号情報決定部３２がイニシエータとなり、ネットワークカメラ１２内の暗号情報決定部１８とネゴシエーションを行なう場合の手順を示す。また、図８および図９は、このときの動作手順を示すフローチャートである。以下では、まず、図８のフローチャートに沿って説明を行なう。
まず、通信装置２４内の暗号情報決定部３２（以下イニシエータ）は、暗号処理部３８がサポートしている暗号アルゴリズムの集合Ａを求める（Ｓ８０１）。そしてイニシエータは、ネゴシエーション開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。
イニシエータは、ネゴシエーションの開始要求を受け付けると（Ｓ８０２）、ＣＰＵ使用率を用いて暗号アルゴリズムを選択する（Ｓ９００）。ステップＳ９００の詳細な手順は、図９のステップＳ９０１〜Ｓ９０５に示すように、通信装置２４がレスポンダの場合（図４のステップＳ５００、すなわち図５）とほぼ同じであるので、ここでは説明を省略する。異なるのは、暗号アルゴリズムを選択する集合が、応答通知可能な暗号アルゴリズム（集合Ｃ）か、サポートしている暗号アルゴリズム（集合Ａ）かの違いのみである。
次に、イニシエータは、選択した暗号アルゴリズムをレスポンダに対して提案する（Ｓ８０３）。
レスポンダでは、はじめに暗号処理部１６がサポートしている暗号アルゴリズムの集合Ｅを求めておく（Ｓ８１１）。その後、イニシエータから提案パケットを受信すると（Ｓ８１２）、提案された暗号アルゴリズムを暗号処理部１６がサポートしているか（すなわち提案された暗号アルゴリズムが集合Ｅに含まれているか）を判断する（Ｓ８１３）。提案された暗号アルゴリズムを暗号処理部１６がサポートしていない（すなわち提案された暗号アルゴリズムが集合Ｅに含まれていない）場合は、イニシエータに応答を返すことができないのでネゴシエーションに失敗し、次の提案パケットを待つ。提案された暗号アルゴリズムを暗号処理部１６がサポートしている（すなわち提案された暗号アルゴリズムが集合Ｅに含まれている）場合には、その暗号アルゴリズムをイニシエータに対して応答通知し（Ｓ８１４）、応答通知した暗号アルゴリズムを暗号処理部１６に設定する（Ｓ８１５）。
イニシエータでは、応答パケットを受信すると（Ｓ８０４）、応答通知された暗号アルゴリズムを暗号処理部３８に設定する（Ｓ８０５）。
以上のように、本実施の形態によれば、イニシエータに対して応答通知する、もしくはレスポンダに対して提案する暗号アルゴリズムを選択する際に、ＣＰＵリソースが不足しない範囲で暗号強度の最も高いものを選択することができる。よって、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション３４のような暗号通信を必要とするアプリケーションとＴＶ録画のようなその他の処理とを並行して行ったときのＣＰＵリソースの不足を防ぐことができる。
なお、本実施の形態ではレスポンダに対して提案する暗号アルゴリズムは１つであるとしたが、優先順位を低くしておけば、他の暗号アルゴリズムを複数提案してもよい。
また、本実施の形態ではネットワークカメラアプリケーション３４以外のアプリケーションはＴＶ録画のみとしていたが、ＴＶ録画以外の他のアプリケーションが存在した場合には、上述の「ＣＰＵＲｅｃｏｒｄ」を、「暗号アルゴリズムネゴシエーションの対象となる暗号通信以外の全てのアプリケーションが使用するＣＰＵ使用率の合計」として読み替えることで、同様の処理が可能である。
また、本実施の形態の説明中で「ネットワークカメラアプリケーション３４が既に開始されており、暗号アルゴリズムとしてｚが用いられていた場合には、ＣＰＵＲｅｃｏｒｄ＝ＣＰＵＵｔｉｌ−ＣＰＵＣａｍｅｒａ（ｚ）のように、録画アプリケーション２８に必要なＣＰＵリソースを求めることができる。」と記載したが、ＣＰＵＵｔｉｌがα［％］を越えていた場合には、この方法ではＣＰＵＲｅｃｏｒｄを小さく見積もっていることになり（その理由は後述する）、その結果、ステップＳ５０２、Ｓ９０２で選択した暗号アルゴリズムを用いて暗号通信を行っても、ＣＰＵ利用率がα［％］を越えてしまう可能性がある。このような問題を回避するために、ステップＳ５０１、Ｓ９０１で取得したＣＰＵ使用率がα［％］を越えていた場合には、集合Ｃ（レスポンダの場合）もしくは集合Ａ（イニシエータの場合）のうち最も処理負荷の低い暗号アルゴリズムを選択してもよい。
「ＣＰＵＵｔｉｌがα［％］を越えている」とは、ＣＰＵＵｔｉｌを計測したときに、録画アプリケーション２８が必要なＣＰＵリソースを完全には確保できていないことを意味する。具体的な例で説明する。ＴＶ録画をするのに必要なＣＰＵリソースであるＣＰＵＲｅｃｏｒｄが８０％であるとする。また、暗号アルゴリズムｚを利用した場合に、ネットワークカメラアプリケーション３４が必要とするＣＰＵリソースであるＣＰＵＣａｍｅｒａ（ｚ）が４０％であったとする。また、α＝９５％とする。ＣＰＵがＴＶ録画とネットワークカメラアプリケーション３４（暗号処理を含む）を実行している場合、必要なＣＰＵリソースは、８０％＋４０％＝１２０％となるが、ＣＰＵ使用率が１００％を越えることはないので、ＣＰＵ使用率の計測値ＣＰＵＵｔｉｌは、このとき、１００％に近い値（α＝９５％を越える値、例えば９８％）として計測される。このとき、ＴＶ録画やネットワークカメラアプリケーション３４は正常に動作できていない状態にある。このような状態で計測したＣＰＵＵｔｉｌをもとにＣＰＵＲｅｃｏｒｄを計算すると、ＣＰＵＲｅｃｏｒｄ＝ＣＰＵＵｔｉｌ−ＣＰＵＣａｍｅｒａ（ｚ）は、９８％−４０％＝５６％となる。正しくは８０％であるべきところを５６％と誤って計算してしまう。すなわち、ＣＰＵＲｅｃｏｒｄを実際よりも小さく見積もってしまうことになる。ここで、例えばＣＰＵＣａｍｅｒａ（ｙ）＝３０％となる暗号アルゴリズムが存在した場合、ＣＰＵＲｅｃｏｒｄ＋ＣＰＵＣａｍｅｒａ（ｙ）＝５６％＋３０％＝８６％＜９５％（α）となり、暗号アルゴリズムｙを選択することができる。しかし、ＴＶ録画をするのに本当に必要なＣＰＵリソースは８０％であるので、ＴＶ録画およびネットワークカメラアプリケーション３４を実行するのに本当に必要なＣＰＵリソースは、８０％＋３０％＝１１０％＞αとなってしまい、やはり正常に動作することができない。いいかえると、ＣＰＵＵｔｉｌ＞αと計測された場合は、その時点で実行されているアプリケーションに対して十分なＣＰＵリソースが割り当てられているとは限らないということになる。よって、ＣＰＵＵｔｉｌ＞αと判定され、正常な動作ができていないと推定される場合には、本当のＣＰＵＲｅｃｏｒｄを求めることができず、適切な暗号アルゴリズムの選択ができないので、暗号アルゴリズムを変更した後に正常な動作をする可能性が比較的高い、最も処理負荷の低い暗号アルゴリズムを選択してもよいのである。もちろん、最も処理負荷の低い暗号アルゴリズムを選択したからといって、正常に動作するようになるという保証は、必ずしもないので、その場合は、異常動作を報告するモードに移るようにしてもよい。このモードにおいて、不要不急のアプリケーションの処理を一時停止するかその処理速度を遅くして、必要なＣＰＵリソースを確保するなどの処理を行なえばよい。
（実施の形態２）
次に実施の形態２について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
次に実施の形態２について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態２では、実施の形態１と違い、ネットワークカメラアプリケーション３４を実行するのに必要なＣＰＵリソースが分からない場合にでも適用できる方法を説明する。
＜通信装置２４がレスポンダとなる場合＞
図１０および図１１は、通信装置２４内の暗号情報決定部３２がレスポンダとなる場合のフローチャートである。以下では、まず図１０のフローチャートに沿って説明を行なう。
図１０および図１１は、通信装置２４内の暗号情報決定部３２がレスポンダとなる場合のフローチャートである。以下では、まず図１０のフローチャートに沿って説明を行なう。
まず、通信装置２４内の暗号情報決定部３２（以下レスポンダ）は、暗号処理部３８がサポートしている暗号アルゴリズムの集合Ａを求める（Ｓ１００１）。こうして、ネットワークカメラ１２内の暗号情報決定部１８（以下イニシエータ）からの提案パケットを待つ状態になる。
イニシエータは、まずネゴシエーションの開始要求を受け付け（Ｓ１０１１）、ネゴシエーションを開始する。すなわち、１つもしくは複数の暗号アルゴリズムの提案を含むパケットをレスポンダに送信する（Ｓ１０１２）。この提案パケットを受信したレスポンダでは、提案されたアルゴリズムの集合Ｂをパケットから読み取る（Ｓ１００２）。レスポンダが応答通知可能な暗号アルゴリズム（集合Ｃ）は、イニシエータによって提案された暗号アルゴリズム（集合Ｂ）のうち、暗号処理部３８がサポートしているもの（集合Ａ）であり、Ｃ＝Ａ∩Ｂとして求められる（Ｓ１００３）。
次に、レスポンダは、集合Ｃから暗号アルゴリズムを選択する（Ｓ１１００）。図１１のフローチャートを用いてこのステップＳ１１００の詳細を説明する。
まず、レスポンダは、この暗号アルゴリズムネゴシエーションが暗号通信開始前のものかどうかを判断する（Ｓ１１０４）。暗号通信開始前の場合は、暗号強度よりもＣＰＵ負荷を軽減することを優先して、集合Ｃのうち最も処理負荷の低い暗号アルゴリズムを応答通知する（Ｓ１１０２）。
暗号通信を既に開始している場合には、そのときのＣＰＵ使用率に応じて、レスポンダは応答通知する暗号アルゴリズムを切り替える。まず、リソース監視部３０から、現状態での、すなわち現在使用中の暗号アルゴリズムなどを含めたＣＰＵ使用率ＣＰＵＵｔｉｌを取得する（Ｓ１１０３）。次に、暗号アルゴリズムを切り替える際の閾値として、２つの値γ［％］とδ［％］（γ≧δ）を用いる。γ、δの値は例えば９０［％］、７０［％］などとあらかじめ決めておく。そして、δ＜ＣＰＵＵｔｉｌ＜γの場合には、ＣＰＵ使用率が高すぎず低すぎず適当であると判断し、現在使用している暗号アルゴリズムを選択する（Ｓ１１０４、Ｓ１１０８、Ｓ１１０７）。
ＣＰＵＵｔｉｌ≧γの場合（Ｓ１１０４）は、レスポンダは、ＣＰＵ負荷が高すぎると判断し、現在使用している暗号アルゴリズムよりもＣＰＵ負荷が低い暗号アルゴリズムを選択する。ただし、できるだけ強固な暗号アルゴリズムを使用するために、現在使用している暗号アルゴリズムよりもＣＰＵ負荷が低い暗号アルゴリズムがある場合には、その中で最も暗号強度の高いものを選択する（Ｓ１１０５、Ｓ１１０６）。現在使用している暗号アルゴリズムが集合Ｃのうち最も負荷の低いものだった場合には、その暗号アルゴリズムを選択する（Ｓ１１０５、Ｓ１１０７）。
ＣＰＵＵｔｉｌ≦δの場合（Ｓ１１０４、Ｓ１１０８）は、レスポンダは、ＣＰＵリソースに余裕があると判断し、現在使用している暗号アルゴリズムよりも暗号強度の高い暗号アルゴリズムがある場合には、その暗号アルゴリズムを選択する（Ｓ１１０９、Ｓ１１１０）。ただし、ＣＰＵ負荷が突然高くなるのを防ぐため、現在使用している暗号アルゴリズムよりも暗号強度が高い暗号アルゴリズムの中で最も処理負荷の低い暗号アルゴリズムを選択する。現在使用している暗号アルゴリズムが集合Ｃのうち最も暗号強度の高いものだった場合には、その暗号アルゴリズムを選択する（Ｓ１１０９、Ｓ１１０７）。
ステップＳ１１０３においては、暗号処理実行中の任意の時刻に、その時点までの一定期間に測定したＣＰＵ使用率の平均値を求める手順により、あらかじめＣＰＵ使用率ＣＰＵＵｔｉｌが求められているものとする。また、このステップＳ１１０３においてＣＰＵ使用率ＣＰＵＵｔｉｌを求めるようにしてもよい。ステップＳ１１０４は、ＣＰＵ使用率と第２基準値γとを比較する手順を実施している。ステップＳ１１０５とステップＳ１１０６は、その比較の結果、ＣＰＵ使用率が第２基準値よりも高い場合に、その時点で使用している暗号アルゴリズムよりも負荷の低い一つもしくは複数の暗号アルゴリズムを選択する手順を実施している。
ステップＳ１１０６、ステップＳ１１０９、ステップＳ１１１０では、暗号強度に基づいて暗号アルゴリズムの選択を行なうが、このために、これらのステップの前またはその中で、暗号強度の順序を求める手順を実行する。図７の暗号処理使用資源表４６には、各暗号アルゴリズムのＥｎｃＲａｔｅ（ｘ）と共に、暗号強度データとして各暗号アルゴリズムの暗号強度の順位が格納されている。この暗号強度データを参照することにより、暗号強度に基づく暗号アルゴリズムの選択が容易に可能となる。
ステップＳ１１０８は、ＣＰＵ使用率と第３基準値δとを比較する手順である。ステップＳ１１０９、ステップＳ１１１０は、ＣＰＵ使用率が第３基準値よりも低い場合において、その時点で使用している暗号アルゴリズムよりも暗号強度の高い一つもしくは複数の暗号アルゴリズムを選択する手順を実施している。
ステップＳ１１０４とステップＳ１１０８で、ＣＰＵ使用率と第２基準値γおよび第３基準値δとを比較し、ＣＰＵ使用率が第２基準値γより低く第３基準値δより高い場合は、ステップＳ１１０７において、その時点で使用している暗号アルゴリズムを選択する手順を実施することになる。
以降は再び図１０に戻って説明する。まず、レスポンダは、ステップＳ１１００で選択した暗号アルゴリズムをイニシエータに対して応答通知する（Ｓ１００４）。
次に、応答通知した暗号アルゴリズムを実際に利用するために、暗号処理部３８にその暗号アルゴリズムを設定する（Ｓ１００５）。一方、イニシエータでは、レスポンダからの応答パケットを受信し（Ｓ１０１３）、応答通知された暗号アルゴリズムをネットワークカメラ１２内の暗号処理部１６に設定する（Ｓ１０１４）。
＜通信装置２４がイニシエータとなる場合＞
次に、通信装置２４内の暗号情報決定部３２がイニシエータとなり、ネットワークカメラ１２内の暗号情報決定部１８とネゴシエーションを行なう場合の手順を示す。また、図１２および図１３は、このときの動作手順を示すフローチャートである。以下では、まず、図１２のフローチャートに沿って説明を行なう。
次に、通信装置２４内の暗号情報決定部３２がイニシエータとなり、ネットワークカメラ１２内の暗号情報決定部１８とネゴシエーションを行なう場合の手順を示す。また、図１２および図１３は、このときの動作手順を示すフローチャートである。以下では、まず、図１２のフローチャートに沿って説明を行なう。
まず、通信装置２４内の暗号情報決定部３２（以下イニシエータ）は、暗号処理部３８がサポートしている暗号アルゴリズムの集合Ａを求める（Ｓ１２０１）。そしてイニシエータは、ネゴシエーション開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。
イニシエータは、ネゴシエーションの開始要求を受け付けると（Ｓ１２０２）、ＣＰＵ使用率を用いて暗号アルゴリズムを選択する（Ｓ１３００）。ステップＳ１３００の詳細な手順は、図１３のステップＳ１３０１〜Ｓ１３１０に示すように、通信装置２４がレスポンダの場合（図１０のＳ１１００、すなわち図１１）とほぼ同じであるので、ここでは説明を省略する。異なるのは、暗号アルゴリズムを選択する集合が、応答通知可能な暗号アルゴリズム（集合Ｃ）か、サポートしている暗号アルゴリズム（集合Ａ）かの違いのみである。
そして、イニシエータは、選択した暗号アルゴリズムをレスポンダに対して提案する（Ｓ１２０３）。
レスポンダでは、はじめに暗号処理部１６がサポートしている暗号アルゴリズムの集合Ｅを求めておく（Ｓ１２１１）。その後、イニシエータから提案パケットを受信すると（Ｓ１２１２）、提案されたアルゴリズムを暗号処理部１６がサポートしているか（すなわち提案された暗号アルゴリズムが集合Ｅに含まれているか）を判断する（Ｓ１２１３）。提案された暗号アルゴリズムを暗号処理部１６がサポートしていない（すなわち提案された暗号アルゴリズムが集合Ｅに含まれていない）場合は、イニシエータに応答を返すことができないのでネゴシエーションに失敗し、次の提案パケットを待つ。提案された暗号アルゴリズムを暗号処理部１６がサポートしている（すなわち提案された暗号アルゴリズムが集合Ｅに含まれている）場合には、その暗号アルゴリズムをイニシエータに対して応答通知し（Ｓ１２１４）、応答通知した暗号アルゴリズムを暗号処理部１６に設定する（Ｓ１２１５）。
イニシエータでは、応答パケットを受信すると（Ｓ１２０４）、応答通知された暗号アルゴリズムを暗号処理部３８に設定する（Ｓ１２０５）。
以上のように、本実施の形態によれば、イニシエータに対して応答通知する、もしくはレスポンダに対して提案する暗号アルゴリズムを選択する際に、ＣＰＵ使用率に応じて、現在使用している暗号アルゴリズムをより適切な暗号アルゴリズムに切り替えることができる。よって、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション３４のような暗号通信を必要とするアプリケーションと、ＴＶ録画のようなその他の処理を並行して行ったときの、ＣＰＵリソースの不足を防ぐことができる。
なお、本実施の形態ではレスポンダに対して提案する暗号アルゴリズムは１つであるとしたが、優先順位を低くしておけば、他の暗号アルゴリズムを複数提案してもよい。
（実施の形態３）
次に実施の形態３について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
次に実施の形態３について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態３では、通信装置２４において定期的にＣＰＵ使用率の変化を検知し、あらかじめ定められたタイミングではなく、ＣＰＵ使用率が変化したタイミングで、通信装置２４内の暗号情報決定部３２がイニシエータとなり、ネットワークカメラ１２内の暗号情報決定部１８とネゴシエーションを行なう。
また、図１４および図１５は、実施の形態３の動作手順を示すフローチャートである。以下では、まず図１４のフローチャートに沿って説明を行なう。
まず、暗号情報決定部３２は、暗号処理部３８がサポートしている暗号アルゴリズムの集合Ａを求める（Ｓ１４０１）。また、暗号情報決定部１８は、暗号処理部１６がサポートしている暗号アルゴリズムの集合Ｅを求める（Ｓ１４２１）。
次に、暗号通信開始前に、暗号情報決定部３２、１８の間で、実施の形態１の手順に従って暗号アルゴリズムのネゴシエーションを行なう（Ｓ１４０２、Ｓ１４２２）。そして、このネゴシエーションに従って選択された暗号アルゴリズムを用いて暗号通信が開始される。このとき、暗号情報決定部３２は、この時点でのＣＰＵ使用率をｐｒｅＣＰＵＵｔｉｌとして保持しておく。なお、ここではどちらがイニシエータとなってネゴシエーションを行ってもよい。
さて、その後暗号通信を継続する間、暗号情報決定部３２は、定期的にリソース監視部３０からＣＰＵ使用率ＣＰＵＵｔｉｌを取得する（Ｓ１４０３）。そして、前回ネゴシエーション時のＣＰＵ使用率ｐｒｅＣＰＵＵｔｉｌとの差分ＣＰＵｄｉｆｆを次のように計算する。
ＣＰＵｄｉｆｆ＝ＣＰＵＵｔｉｌ−ｐｒｅＣＰＵＵｔｉｌ
ＣＰＵｄｉｆｆ＝ＣＰＵＵｔｉｌ−ｐｒｅＣＰＵＵｔｉｌ
ここで、暗号情報決定部３２は、ＣＰＵＵｔｉｌとｐｒｅＣＰＵＵｔｉｌとの差が、ある一定値β［％］よりも大きいかどうかを、次の不等式が成り立つどうかで判定する（Ｓ１４０４）。
｜ＣＰＵｄｉｆｆ｜≧β
なお、βの値は、例えば５％のようにあらかじめ定めておく。この式が成り立たないとき、つまり前回のネゴシエーション時にくらべてＣＰＵ使用率の変化がβ［％］未満である場合は、暗号情報決定部３２は、暗号アルゴリズムを変更する必要はないと判断し、ネゴシエーションを行なわない。
｜ＣＰＵｄｉｆｆ｜≧β
なお、βの値は、例えば５％のようにあらかじめ定めておく。この式が成り立たないとき、つまり前回のネゴシエーション時にくらべてＣＰＵ使用率の変化がβ［％］未満である場合は、暗号情報決定部３２は、暗号アルゴリズムを変更する必要はないと判断し、ネゴシエーションを行なわない。
上記の不等式が成り立つとき、つまり、前回のネゴシエーション時にくらべてＣＰＵ使用率の変化がβ［％］以上であるときは、暗号情報決定部３２は、暗号アルゴリズムを変更する必要があるかもしれないと判断し、使用すべき暗号アルゴリズムを求める（Ｓ１５００）。ステップＳ１５００の詳細な手順は、図１５のステップＳ１５０１〜Ｓ１５０６に示すように、実施の形態１の通信装置２４がイニシエータの場合（図８のＳ９００、すなわち図９）とほぼ同じであるので、ここでは説明を省略する。異なるのは、提案パケットを必ず送信するのか、暗号アルゴリズムが変更となるときにだけ送信するのかの違いのみである（Ｓ１５０３、Ｓ１５０５）。その結果、暗号アルゴリズムを変更する必要がある場合は、暗号情報決定部３２は、イニシエータとして、提案パケットをレスポンダに対して送信する（Ｓ１４０５）。
次に、レスポンダは、受信した提案パケットに対して、応答パケットを送信し（Ｓ１４２３〜Ｓ１４２５）、応答通知した暗号アルゴリズムを暗号処理部１６に設定する（Ｓ１４２６）。また、イニシエータは、応答パケットを受信すると（Ｓ１４０６）、応答通知された暗号アルゴリズムを暗号処理部３８に設定する（Ｓ１４０７）。以上の手順（Ｓ１４０６、Ｓ１４０７、Ｓ１４２３〜Ｓ１４２６）は、実施の形態１の通信装置２４がイニシエータの場合（図８のＳ８０４、Ｓ８０５、Ｓ８１２〜Ｓ８１５）と全く同じであるので、詳細な説明は省略する。
最後に、次回のステップＳ１４０３でＣＰＵ使用率の変化を計算するために、ここでのＣＰＵ使用率ＣＰＵＵｔｉｌの値をｐｒｅＣＰＵＵｔｉｌに設定する（Ｓ１４０８）。
以上のように、本実施の形態によれば、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション３４のような暗号通信を必要とするアプリケーションと、ＴＶ録画のようなその他の処理を並行して行ったときの、ＣＰＵリソースの不足を防ぐことができる。また、ＣＰＵ使用率に変化が起こったときに暗号アルゴリズムの見直しが行われるため、柔軟にかつ効率的に、最適な暗号アルゴリズムを選択することができる。
なおここではβの値は一定値としているが、現在使用している暗号アルゴリズムや、その他の集合Ａに含まれる暗号アルゴリズムが必要とするＣＰＵリソース等に基づいてβ値を動的に変化させてもよい。たとえば、複数の暗号アルゴリズムの各ＣＰＵ使用率間の差に比べてβ値が小さいと、その時のＣＰＵ使用率の変化が少しであってもその変化量はβ値を超えるのでステップＳ１５００の選択判定を開始することになるが、暗号アルゴリズムを変更するほどのＣＰＵ使用率の余裕がないことが分かり、選択判定が無駄になる。選択中の暗号アルゴリズムとＣＰＵ使用率において隣接するアルゴリズムとのＣＰＵ使用率の差値をβ値とし、選択中の暗号アルゴリズムによってβ値を動的に変えるようにすれば、無駄な処理を削減できる。
（実施の形態４）
次に実施の形態４について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
次に実施の形態４について説明する。ただし、全体のシステム構成など、実施の形態１と変わらない部分の説明はここでは省略し、実施の形態１の図面を援用する。実施の形態１と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態４では、通信装置２４内の暗号情報決定部３２とネットワークカメラ１２内の暗号情報決定部１８とが、暗号アルゴリズムネゴシエーション時に複数の暗号アルゴリズムを合意しておく。そして、暗号化側でパケットを送信する際に、合意した暗号アルゴリズムのうちのどの暗号アルゴリズムを用いて送信パケットの暗号化を行っても、復号化側では正しく復号できるようにする。
以下では、ＣＰＵ使用率にもとづいて暗号アルゴリズムを選択し、その暗号アルゴリズムを用いて送信パケットを暗号化する側の動作手順と、その相手側の動作手順をそれぞれ示す。
図１６および図１７は、実施の形態４の動作手順を示すフローチャートである。図１６の左側および図１７は、ＣＰＵ使用率に基づいて暗号アルゴリズムを選択する側（ここでは通信装置２４内の暗号情報決定部３２とする）の動作手順を、図１６の右側は、相手側（ここではネットワークカメラ１２内の暗号情報決定部１８とする）の動作手順を示している。以下では、まず図１６のフローチャートに沿って説明を行なう。
＜暗号アルゴリズム選択側の動作手順＞
まず、暗号アルゴリズム選択側の動作手順について説明する。暗号アルゴリズム選択側は、暗号アルゴリズム被通知側と暗号アルゴリズムネゴシエーションを行なう（Ｓ１６０１）。このとき、通信相手と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。ここで合意した暗号アルゴリズムの集合を集合Ｆとする。
まず、暗号アルゴリズム選択側の動作手順について説明する。暗号アルゴリズム選択側は、暗号アルゴリズム被通知側と暗号アルゴリズムネゴシエーションを行なう（Ｓ１６０１）。このとき、通信相手と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。ここで合意した暗号アルゴリズムの集合を集合Ｆとする。
次に、パケット送信要求が発生するまで待つ（Ｓ１６０２）。パケット送信要求が発生すると、ＣＰＵ使用率から使用すべき暗号アルゴリズムを選択する（Ｓ１７００）。なお、ステップＳ１７００の暗号アルゴリズム選択方法の詳細は、図１７のステップＳ１７０１〜Ｓ１７０５に示すように、実施の形態１におけるアルゴリズム選択方法（図４のＳ５００、図５）とほぼ同じであるので、ここでは説明を省略する。実施の形態１におけるアルゴリズム選択方法と異なるのは、選択肢となる暗号アルゴリズムの集合が、集合Ｃであるか、集合Ｆであるかの違いのみである。
なお、ここではパケット送信ごとに使用する暗号アルゴリズムを選択するとしているが、複数のパケット毎に、あるいは、一定時間おきに選択するようにしてもよい。
最後に、選択した暗号アルゴリズムで送信パケットを暗号化し送信して（Ｓ１６０３）、パケット送信要求を受け付ける状態に戻る（Ｓ１６０２）。
ステップＳ１６０２において受け付けるパケット送信要求は、ネットワークカメラ１２を制御するための指示をネットワークカメラ１２に送信する場合のようにアプリケーションの動作により発生するものや、ＩＰレイヤなどでのプロトコルの動作により発生するものなどがありうる。典型的な例は、通信装置２４に設けられた操作ボタンを使用者が押すことにより、通信装置２４においてカメラアプリケーションが動作し、このカメラアプリケーションがネットワークカメラ１２に対して映像データパケットの送信を要求する場合である。また、同時に、通信制御用パケットや暗号アルゴリズムネゴシエーションパケットなどを暗号化する場合もある。
ステップＳ１６０３では、ステップＳ１６０２においてその送信要求を受け付けたパケットを暗号化して送信する。
なお、ステップＳ１６０３で送信した暗号パケットをネットワークカメラ１２において復号化する場合は、暗号パケットに付属するＳＡ識別ＩＤ（ＳＰＩ）を参照して、そのパケットがどの暗号アルゴリズムによって暗号化されているかを判別し、暗号の復号化を行なう。このステップは、図１６のフローチャートの中で行なってもよいし、受信パケットの暗号解読のフローチャートにしたがって行なってもよい。
＜相手側の動作手順＞
次に、相手側の動作手順について説明する。まず、相手側は、暗号アルゴリズム選択側と暗号アルゴリズムネゴシエーションを行なう（Ｓ１６２１）。このとき、暗号アルゴリズム選択側と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。そして、通信装置２４から暗号化されたパケットを受信したかどうかを判定し（Ｓ１６２２）、この判定結果がＹＥＳの場合は、このパケットに適用されている暗号アルゴリズムを、暗号処理部１６で使用する暗号アルゴリズムとして設定する（Ｓ１６２３）。
次に、相手側の動作手順について説明する。まず、相手側は、暗号アルゴリズム選択側と暗号アルゴリズムネゴシエーションを行なう（Ｓ１６２１）。このとき、暗号アルゴリズム選択側と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。そして、通信装置２４から暗号化されたパケットを受信したかどうかを判定し（Ｓ１６２２）、この判定結果がＹＥＳの場合は、このパケットに適用されている暗号アルゴリズムを、暗号処理部１６で使用する暗号アルゴリズムとして設定する（Ｓ１６２３）。
次に、パケット送信要求が発生しているかをチェックする（Ｓ１６２４）。パケット送信要求が発生していれば、ステップＳ１６２３で設定された暗号アルゴリズムを用いて送信パケットを暗号化し、送信する（Ｓ１６２５）。
なお、ステップＳ１６２５で送信したパケットを通信装置２４が受信するには、通信装置２４で実行されるステップＳ１６０３とステップＳ１６０２の間に、暗号化データのパケットを受信したかどうかの判断を行ない、受信した場合に暗号解読を行なうステップを付け加えてもよい。また、このフローチャートの手順とは別に、通信装置２４が、暗号化データのパケット受信とその解読を行なう手順を割り込みなどを契機に行なうようにしてもよい。
以上のように、本実施の形態によれば、暗号アルゴリズム選択側と相手側とで、予め複数の暗号アルゴリズムを利用することを合意するため、暗号アルゴリズム選択側が、使用する暗号アルゴリズムを変更するときに、暗号アルゴリズムを折衝し直す必要がない。よって、より柔軟にＣＰＵ負荷を制御することができる。
ところで、実施の形態４においては、ＣＰＵリソースに余裕があった場合、通信装置２４において、それまで使われていた暗号アルゴリズムよりも負荷の高い暗号アルゴリズムが選択され、ネットワークカメラ１２に通知される。しかしながら、その通知の直後に通信装置２４においてＣＰＵ使用率が何らかの理由のために増加した場合に、ＣＰＵ使用率が増加する直前にネットワークカメラ１２で暗号アルゴリズムｘによって暗号化されたカメラ映像パケットを受信した通信装置２４では、ＣＰＵリソースが不足しているためにこのパケットを復号化できない危険がある。このような危険を防止するために、暗号アルゴリズムを使用して通信している場合は、通信装置２４において、ＣＰＵリソースの消費を増やすようなアプリケーションの追加や変更を暗号通信が終わるまで禁止するか、その危険をＯＳやユーザに知らせて適切な処理を行なうようにすればよい。このような危険防止の処理は、本発明の他の実施の形態においても適用できる。
なお、上記実施の形態１〜４では、各アプリケーションによるＣＰＵ使用率の推定値が必要になったときにリソース監視部３０からその推定値を入手するとした。ところで、通信装置２４において実行される可能性のある各種アプリケーションのうち、どのアプリケーションが同時並行して実行されるかが予め分かっている場合が多い。そのようなアプリケーションについては、それぞれ予め単独で実行してみて、リソース監視部３０によりそのときのＣＰＵ使用率をそれぞれ計測し、計測した値を既定の値としてＣＰＵ使用率情報メモリ４４に格納しておき、この既定の値を折衝時に取り出して使用するようにしてもよい。また、同じ組み合わせで実行される可能性のある２つ以上のアプリケーションについて、予め試験的に同時に実行してＣＰＵ使用率を計測したり、過去に同じ組み合わせで実行されている期間のＣＰＵ使用率を計測したりし、この計測結果を既定の値としてＣＰＵ使用率情報メモリ４４に格納しておき、この既定の値を折衝時に取り出して使用するようにしてもよい。また、通信装置２４の設計時に各アプリケーションによるＣＰＵ使用率を算出し、その算出結果を既定の値としてＣＰＵ使用率情報メモリ４４に格納しておいてもよい。
また、ＣＰＵ使用率の仕組みと計測方法については、採用するＣＰＵが適用している仕組みと計測方法に従えばよく、上記説明の例に限定されることはない。
また、本実施の形態では、暗号アルゴリズム選択側が用いた暗号アルゴリズムを、相手側は、暗号アルゴリズム選択側から受信した暗号化パケットに基づいて判断するとしたが、これに替えて、暗号アルゴリズム選択側が、暗号アルゴリズム選択側で用いた暗号アルゴリズムを通知するためのパケットを別途相手側へ送信するようにしてもよい。また、この場合、相手側は、暗号アルゴリズム選択側から通知された暗号アルゴリズムを用いて、暗号アルゴリズム選択側へ送信すべきパケットを暗号化してもよい。
また、上記実施の形態１〜４においては、録画機能を有する通信装置２４における暗号アルゴリズムの選択方法について説明したが、録画機能以外の機能を有する通信装置に対しても本発明を適用できることは言うまでもない。また、通信相手の機器（ネットワークカメラに限らない）も本発明のネゴシエーションの仕組みを有し、その機器内部でのＣＰＵ使用率に従って適用可能な複数のアルゴリズムを選択しながら、両者間でネゴシエーションを行なうことによって最終的に使用するアルゴリズムを選択するようにしてもよい。
（実施の形態５）
図１８は、本発明の実施の形態５に係わる通信装置の構成を示すブロック図である。図１８を参照すると、通信装置は、スケジュール部６４、アプリケーション６０、６２、暗号通信アプリケーション７０、７２、暗号情報決定部７４、通信処理部７８、暗号処理部８０、リソース監視部８２を備えている。以下、本通信装置は、図１に示した通信装置２４と同様に、ＴＶ受信、ＴＶ録画、録画番組の再生、カメラ映像の暗号通信による受信と表示等の機能を有するものとして説明する。
図１８は、本発明の実施の形態５に係わる通信装置の構成を示すブロック図である。図１８を参照すると、通信装置は、スケジュール部６４、アプリケーション６０、６２、暗号通信アプリケーション７０、７２、暗号情報決定部７４、通信処理部７８、暗号処理部８０、リソース監視部８２を備えている。以下、本通信装置は、図１に示した通信装置２４と同様に、ＴＶ受信、ＴＶ録画、録画番組の再生、カメラ映像の暗号通信による受信と表示等の機能を有するものとして説明する。
スケジュール部６４は、リモコンや外部からの予約指令に従って、各アプリケーションの予約の登録、実行時刻の管理と実行の制御を行なう。アプリケーション６０は、一例として、テレビ放送を受信して得られた映像データをハードディスクメモリに録画し、タイムシフトして再生するアプリケーション（図１の録画アプリケーション２８に相当）であり、アプリケーション名をＡとする。テレビ放送の録画をタスクａとし、タイムシフト再生をタスクｃとする。暗号通信アプリケーション７０は、一例として、ネットワークカメラから送られるカメラ映像データを復号化してディスプレイに表示するアプリケーション（図１のネットワークカメラアプリケーション３４に相当）であり、アプリケーション名をＢとする。アプリケーションＢは、タスクｂより成り、暗号アルゴリズムを使用する。
暗号情報決定部７４は、使用する暗号アルゴリズムのネゴシエーションにおける、暗号アルゴリズムの選択・提案・決定に必要な各種情報（例えば、各暗号アルゴリズムが消費する使用資源情報、暗号強度情報など）、および暗号通信に必要な各種情報（例えば、暗号化・復号化に使用する公開鍵、秘密鍵、共有鍵などの鍵に関する情報など）を管理し、使用する暗号アルゴリズムを選択・決定する。
暗号処理部８０は、複数の暗号アルゴリズム処理手段（あるいは暗号アルゴリズム処理手順を実行するプログラム）を備えており、ネゴシエーションパケットの処理や、暗号化・復号化に使用する鍵・公開値・公開鍵・秘密鍵・共有鍵などの作成や、送信するデータの暗号化や、受信したデータの復号化などを行なう。
通信処理部７８は、暗号処理部８０が作成したパケットをインターネット回線網に所定の通信プロトコルの形式にして送信し、インターネット回線網から受信した通信プロトコルの形式のデータからパケットを取り出して暗号処理部８０に渡す。
次に、本実施の形態の通信装置の動作について説明する。
まず、ＴＶ録画を行なう際の動作について説明する。図１８の通信装置において、受像部（図示しない）は、ＴＶ放送データを受信し、続いて、受信されたＴＶ放送データを、アプリケーション６０が、通信装置内蔵の蓄積媒体（図示しない）に記録する。この処理は、アプリケーション６０中のタスクａの処理を本通信装置内蔵のＣＰＵが実行することにより実現される。録画したいチャンネルのＴＶ番組の放送開始時刻から放送終了時刻まで録画を連続的に行なうことで、ＴＶ録画が完了する。
ＴＶ録画の予約は、使用者が予めリモコンを用いて録画チャンネル番号・録画開始時刻・録画終了時刻を指示し、その指示内容をスケジュール部６４が受取って、後述するスケジュール・使用資源表６６に登録することにより行われる。
また、アプリケーション６０は、録画したＴＶ番組をタイムシフトして再生する機能（タスクｃ）を含んでいる。このタイムシフト再生のタスクｃについても、リモコン予約により再生番組番号・再生開始時刻・再生終了時刻が指示され、その指示内容がスケジュール部６４によりスケジュール・使用資源表６６に登録される。
次に、ネットワークカメラの映像をディスプレイに表示する際のシステムの動作について説明する。この処理は、暗号通信を行なうための前処理と、実際にネットワークカメラアプリケーションを動作させる処理の２つに分かれる。暗号通信を行なうための前処理については後述し、はじめに、実際にネットワークカメラアプリケーションを動作させる処理の概要について述べる。ネットワークカメラ側の処理は、図４３や、実施の形態１（図１）で説明したのでここでは説明を省略する。図１８の通信装置では、通信処理部７８でインターネット回線網から映像データに基づく暗号化パケットを受信し、暗号処理部８０で復号化し、復号化された映像データを暗号通信アプリケーション７０に渡し、暗号通信アプリケーション７０は、映像データを所定の位置・大きさでディスプレイ（図示しない）に出力する。そして、ディスプレイが映像を表示する。以上のようにして、ネットワークカメラで撮影された映像がディスプレイに表示される。
ネットワークカメラの映像データを受信する時間帯の予約指示も、予めリモコンからスケジュール部６４に対して行なわれ、スケジュール・使用資源表６６に登録される。
次に、スケジュール・使用資源表６６について説明する。図１９にその一例を示す。図１９において、ＴＶ録画アプリケーションＡ（アプリケーション６０）は、タスクａとタスクｃよりなる。ＴＶ録画のタスクａは、２００２年１１月１日の１２：００から１３：００までの番組を予約録画するように指令されているので、開始時刻欄と終了時刻欄に、その旨が登録されている。図示しないが、この他のデータとして、チャンネル番号や番組コードなども登録される。タスクｃは、録画した番組を３０分遅れでタイムシフトして見るアプリケーションＡの機能の一部であり、２００２年１１月１日の１２：３０から１３：３０まで実行するように予約され、登録されている。図示しないが、この他のデータとして、録画された番組のチャンネル番号や番組コード、あるいはＨＤＤ内の番組ファイル管理コードなどが登録される。アプリケーションＢ（暗号通信アプリケーション７０）は、ネットワークカメラの映像データの受信機能と表示機能を実現するものであり、タスクｂより成る。このタスクｂは、２００２年１１月１日の１１：４５から以降継続して実行されるように、リモコンにより指示されており、スケジュール・使用資源表６６の開始時刻と終了時刻に、その旨が登録されている。
また、スケジュール・使用資源表６６には、各タスクａ、ｂ、ｃ、それぞれの実行に必要とする使用資源の量、すなわちＣＰＵの処理能力、メモリ量、通信する場合のデータ転送量が、それぞれ、平均使用ＣＰＵ資源（メガインストラクション／秒：ＭＩＰＳ）、平均使用メモリ資源（メガバイト：ＭＢ）、暗号通信の平均データ転送量（メガビット／秒：Ｍｂｐｓ）として記憶されている。タスクａ、ｃについては、暗号通信を行なわないので、暗号通信の平均データ転送量は０Ｍｂｐｓである。暗号通信欄には暗号通信の有無を記載してある。タスクｂについては暗号通信欄が「する」となっている。また、必要暗号強度の欄には、暗号通信の際の必要暗号強度を指定している。この例では、タスクｂにおいて利用する暗号アルゴリズムは、暗号強度が１位、２位、３位のものの中から選ぶように指定されている。
暗号情報決定部７４は、内部に暗号処理使用資源表７６を備えている。暗号処理使用資源表７６の例を、図２０に示す。図２０において、暗号処理部８０が保有している２種の暗号アルゴリズム（ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ）について、それぞれの使用資源の量、すなわち平均使用ＣＰＵ資源（単位：ＭＩＰＳ／Ｍｂｐｓ）、平均使用メモリ資源（ＭＢ）、暗号強度順位が記憶されている。平均使用ＣＰＵ資源の単位は、この例においては、１Ｍｂｐｓのデータ転送量を暗号化・復号化する際に必要なＣＰＵ処理能力をしめす。データ転送量が多いほど、暗号化・復号化の処理能力が比例的に多く必要になる。１Ｍｂｐｓのデータを転送する場合は、それぞれ１００ＭＩＰＳ、３００ＭＩＰＳのＣＰＵ処理能力を消費することを示している。
図２１は、スケジュール・使用資源表６６と暗号処理使用資源表７６に基づくＣＰＵ使用率の時間推移を示した図である。ＣＰＵ使用率は、ＣＰＵの最大処理能力を１０００ＭＩＰＳとした場合の％で表示している。破線は暗号アルゴリズムとしてＤＥＳ−ＣＢＣを採用した場合のＣＰＵ使用率を示しており、一点鎖線は暗号アルゴリズムとして３ＤＥＳ−ＣＢＣを採用した場合のＣＰＵ使用率を示している。タスクａとタスクｃに加えてタスクｂを処理する１２：３０〜１３：００の区間で、ＣＰＵ使用率が最も高くなっている。ＣＰＵ使用率は、処理量の瞬間的揺らぎや予測できない緊急の処理に対応できるように、余裕を残すようにするのが一般的である。正常な処理を行なうのに支障がない許容総平均ＣＰＵ使用率を５０％とした場合、図２１では、３ＤＥＳ−ＣＢＣの場合、１２：００〜１３：００においてＣＰＵ使用率が５０％を超えるため正常な処理に支障をきたす恐れがあることになる。一方、ＤＥＳ−ＣＢＣなら全時間においてＣＰＵ使用率が５０％以下である。
本実施の形態では、スケジュール・使用資源表６６と暗号処理使用資源表７６を使用して、許容資源使用量、すなわち許容総平均ＣＰＵ使用率（または許容ＣＰＵ処理能力）を超えないように、暗号アルゴリズムをスケジューリングする。
このために、次のようなスケジュール解析処理を行なう。スケジュール部６４は、スケジュール・使用資源表６６の内容と内部時計（図示しない）を監視する。そして、内部時計の現在時刻より一定時間後（例えば、５分後）のイベントの有無を調べる。図１９のスケジュール・使用資源表によれば、現在時刻１１：４０以前では、５分後のイベントがないので、スケジュール部６４は待機状態である。１１：４０になると、スケジュール部６４は５分後にイベントが予定されていることを検知する。するとスケジュール部６４は、スケジュール・使用資源表６６内に登録された全タスクを調べ、それらの開始時刻、終了時刻によって区切られる各イベント区間（ここでは、区間（１１：４５〜１２：００）、区間（１２：００〜１２：３０）、区間（１２：３０〜１３：００）、区間（１３：００〜１３：３０）、区間（１３：３０〜未定））ごとに、平均使用ＣＰＵ資源の合計値を算出する。暗号通信を行なうタスクｂでは、暗号強度第３位以上の暗号アルゴリズムから選択することが指定されているので、暗号処理使用資源表７６に記載された各暗号アルゴリズムそれぞれを適用した場合の平均使用ＣＰＵ資源の合計値を算出する。
なお、５分後のイベントの有無を調べる代わりに、何らかのアプリケーションの実行が予約された時点において、上記平均使用ＣＰＵ資源の合計値を算出するようにしてもよい。
図２２は、合計値を算出するためにスケジュール部６４が作成するイベント・使用資源表６８の例である。図２２（１）は、ＤＥＳ−ＣＢＣを使用した場合のイベント・使用資源表６８である。各イベント時刻毎に、タスク名毎の動作状況（稼動／非稼動）とその使用資源の欄、暗号アルゴリズム名とその使用資源欄、および使用資源合計の欄が設けられる。タスクが複数ある場合は、その数だけの欄が設けられる。各欄には、そのイベント時刻から次の行のイベント時刻までの間に実行すべきタスクや暗号アルゴリズムについての記入が行われる。すなわち、各イベント時刻から次のイベント時刻の間に予約されているタスク名とその使用資源量を記載する。あるタスクがある時刻で終了する場合は、その終了時刻をイベント時刻の欄に記入した行を設け、終了すべきタスク名を記載しないようにすればよい。暗号アルゴリズムを使用する場合は、暗号アルゴリズム名とその使用資源量も記載する。ＤＥＳ−ＣＢＣは、図２０の例では１００ＭＩＰＳ／Ｍｂｐｓであるが、カメラアプリケーション（アプリケーションＢ）における映像データの暗号通信の平均データ転送量が、図１９の例では１Ｍｂｐｓであるので、ＤＥＳ−ＣＢＣの平均使用ＣＰＵ資源は１００ＭＩＰＳになる。図２２（２）は、３ＤＥＳ−ＣＢＣを使用した場合のイベント・使用資源表６８である。図２２（１）および図２２（２）の使用資源合計の欄をＣＰＵ処理能力１０００ＭＩＰＳに対して％表示すれば、それぞれ、図２１の破線と一点鎖線のＣＰＵ使用率（％）の時間推移になる。
スケジュール部６４は、作成したイベント・使用資源表６８の使用資源合計欄を調べ、最大ＣＰＵ処理能力１０００ＭＩＰＳの許容総平均ＣＰＵ使用率５０％である許容ＣＰＵ処理能力５００ＭＩＰＳを常に超えないような全ての暗号アルゴリズムを選択し、選択した暗号アルゴリズム名を暗号情報決定部７４に通知する。暗号情報決定部７４は、通知された暗号アルゴリズム名と暗号処理使用資源表７６とを参照して通知された暗号アルゴリズムの中から最も暗号強度が強いものを選択する。本実施の形態では、ＤＥＳ−ＣＢＣのみが暗号情報決定部７４に通知されるので、この暗号アルゴリズムが選択される。
つぎに、暗号情報決定部７４は、採用したＤＥＳ−ＣＢＣを使用することをスケジュール部６４に通知する。スケジュール部６４は、通知された暗号アルゴリズムの使用をスケジュール化する。この例では、図２２（１）を選択する。以上で、スケジュール解析に基く暗号アルゴリズムの選択とその使用スケジュールが作成できた。
スケジュール部６４は、通知された暗号アルゴリズム（ここではＤＥＳ―ＣＢＣ）に対応する図２２（１）のイベント・使用資源表６８を使用して、予約された各アプリケーションの起動・実行・停止を制御する。スケジュール部６４は、イベント・使用資源表６８（図２２（１））を常時参照しており、内部時計が１１：４５になると、スケジュール部６４は、暗号通信アプリケーション７０に対してタスクｂを起動するよう指示し、暗号処理部８０に対してＤＥＳ−ＣＢＣを使用して暗号通信の前処理を行なうように指示する。
暗号処理部８０は、暗号通信の前処理として、暗号通信に必要な共有鍵の作成のため、通信相手である図４３のネットワークカメラの暗号処理部２０４との間で、ネゴシエーションを行ない、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、ＩＫＥ、ＩＰｓｅｃなどの仕様にしたがって、共有鍵を作成する。暗号処理部８０、２０４の両方で共有鍵の作成が終了すると、通信装置では、暗号処理部８０が暗号通信アプリケーション７０に暗号通信ができることを通知し、ネットワークカメラでは、暗号処理部２０４が暗号通信アプリケーション２００に暗号通信ができることを通知する。通知を受けた暗号通信アプリケーション２００は、カメラの映像データを暗号処理部２０４に送り込み、暗号処理部２０４はＤＥＳ−ＣＢＣによりこの映像データを暗号化し、通信処理部２０６は暗号化された映像データパケットを作成してインターネット回線網を介して通信処理部７８にパケットを送る。暗号処理部８０は、通信処理部７８より受信したデータを受取って暗号の復号化を行ない、映像データを暗号通信アプリケーション７０に渡す。暗号通信アプリケーション７０は、既に説明したように、映像をディスプレイに表示する。スケジュール部６４は、内部時計を参照して現在時刻が１２：００になったことを検知すると、イベント・使用資源表６８に従い、タスクｂを継続しつつ、タスクａ（すなわちアプリケーション６０）を起動する。１２：３０になるとさらにタスクｃを起動する。１３：００になるとタスクａを停止する。１３：３０になるとタスクｃを停止する。すなわち、各イベント時刻になると、そのイベント時刻の行の内容をひとつ前のイベント時刻の行の内容と比較し、前行から新たに追加されたタスクや暗号アルゴリズムを起動し、前行から記載がなくなったタスクや暗号アルゴリズムがあれば、それらを停止する。
以上のように、この実施の形態５の通信装置あるいはアルゴリズム選択方法では、スケジュール部６４が、スケジュール・使用資源表６６の予約内容と暗号処理使用資源表７６のデータを調べることにより、使用ＣＰＵ資源量が許容ＣＰＵ処理能力を超えないような暗号アルゴリズムが選択されるようなスケジュールを作成するようにした。従って、暗号通信の実行中に使用ＣＰＵ資源量が許容ＣＰＵ処理能力を超えてしまってシステムが破綻したり暗号通信が中断したりする危険性を予め排除できる。
また、本実施の形態によれば、将来の動作を考慮して暗号アルゴリズムの選択など、暗号設定情報を決定することができるため、途中で暗号アルゴリズムを切り替えなくとも、処理資源が枯渇することを防止できる。また、刻々かわる資源の使用状態に応じて暗号アルゴリズムの選択などを制御する動的な資源使用制御にくらべて、手後れになる危険性を低減できる。
各タスクａ、ｂ、ｃの使用資源の量である、平均使用ＣＰＵ資源、平均使用メモリ資源、平均データ転送量などの数値は、予め通信装置の製造や出荷時にアプリケーション６０や、暗号通信アプリケーション７０の内部に記憶しておいてもよいし、あるいは各アプリケーションプログラムをインターネット回線網やＴＶデータ放送を通じて外部からダウンロードする際に、アプリケーション６０や、暗号通信アプリケーション７０の内部に記憶しておいてもよい。暗号アルゴリズムの平均使用ＣＰＵ資源・平均使用メモリ資源・暗号強度順位・後述する前処理命令数などは、暗号処理部８０にテーブルを設け、このテーブルに暗号・復号情報として記憶しておいてもよい。この場合は、これらの暗号・復号情報を暗号情報決定部７４が読み出して暗号処理使用資源表７６に書きこむ。あるいは、暗号処理使用資源表７６中に記憶しておいてもよい。
あるいは、暗号アルゴリズムの平均使用ＣＰＵ資源・平均使用メモリ資源・平均データ転送量・後述する前処理命令数などを前回実行時に計測しておき、計測したデータを図２のＣＰＵ使用率情報メモリ４４のような記憶部に記憶するようにしてもよい。この計測はリソース監視部８２において行ない、計測した情報を暗号情報決定部７４に通知し、暗号情報決定部７４がこのデータを上記記憶部に記憶しておく。そして、予約指示を受けてスケジュール・使用資源表６６を作成する際に、暗号情報決定部７４はこれらのデータを上記記憶部から読み出してスケジュール・使用資源表６６の所定欄に書き込む。暗号アルゴリズムに関するデータは、計測結果を暗号処理使用資源表７６に転送してもよい。一般に、ＣＰＵ処理能力の使用量の計測は、モニタプログラムやカーネルプログラムの一部を利用して行なう。実行タスクのＣＰＵ処理能力の使用量をＣＰＵ自身が計測できる場合は、その計測結果をＣＰＵが暗号情報決定部７４に通知するようにしてもよい。
なお、本実施の形態では、図２２（１）と図２２（２）に示すように、暗号アルゴリズム毎に別々のイベント・使用資源表６８を設けているが、後述する実施の形態７で説明する図２５や図２６のように、表の共通部分をまとめてひとつの表の形にしてもよい。
図２３は、上記説明した処理を行なう通信装置のハードウェア構成の例である。図２３において、ＣＰＵ９４、ＲＯＭ９６、ＲＡＭ９８、ＨＤＤ１０４、モデム１１６は、転送手段９２であるバスラインに接続されている。このような構成は、標準的なコンピュータシステムの構成である。ＲＯＭ９６には、システム起動用のプログラムや、書き換える必要のないデータが格納されている。ＨＤＤ１０４内のエリア１０６には、システム全体の統括や種々の制御を行なうオペレーションシステム（ＯＳ）のような制御プログラム、ＣＰＵ９４をリソース監視部８２として機能させるためのリソース監視部プログラム、ＣＰＵ９４を通信処理部７８として機能させるための通信処理部プログラムが格納されている。エリア１０８には、ＣＰＵ９４をスケジュール部６４として機能させるためのスケジュール部プログラム、ＣＰＵ９４を暗号情報決定部７４として機能させるための暗号情報決定部プログラムが格納されている。エリア１１０には、ＣＰＵ９４を暗号処理部８０として機能させるための暗号処理部プログラム、暗号アルゴリズムのプログラムが格納されている。エリア１１２には、アプリケーションプログラム、暗号通信アプリケーションプログラムが格納されている。エリア１１４のファイル部には、録画したテレビ番組のデータが格納される。アンテナ８４とチューナ８６により受信されたテレビ番組のトランスポートストリームは、エリア１１２からＲＡＭ９８にロードされたアプリケーション６０に従ってＣＰＵ９４によりデコードされ、そのデコード結果がエリア１１４のファイル部に格納（録画）される。また、録画されたデータは、所定のタイムシフト時間後に読み出され、ＣＰＵ９４によってＡＶデコードの処理が行なわれ、デコードされた音声データと映像データは音声処理８８と表示処理９０を介して音声出力と映像出力として出力される。リモコン１０２の操作により指示される予約情報は、リモコンＩＦ（インタフェース）１００を介してスケジュール部プログラムが受取り、スケジュール部プログラムはこれをスケジュール・使用資源表６６に登録する。その後、ＣＰＵ９４は、制御プログラムに従って、スケジュール部プログラム、暗号情報決定部プログラム、暗号処理部プログラム、暗号アルゴリズムプログラム、アプリケーションプログラム、暗号通信プログラム、リソース監視部プログラム、および通信処理部プログラムをＲＡＭ９８上に順次ロードし、各プログラムにしたがって上記説明した処理を行なう。
次に、実施の形態５を基本として、その他の実施の形態について説明してゆく。以下、各実施の形態の説明においては、ブロック構成が実施の形態５の場合と同じ部分については繰り返しの説明を省き、異なる部分を中心に説明する。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
（実施の形態６）
図１８で説明した実施の形態５の通信装置においては、暗号通信に先立つ前処理、すなわち各種暗号通信にかかわるパラメータのネゴシエーションや共有鍵の交換の処理に無視できない時間がかかる場合には、予約した時間どおりに暗号通信を開始できないという問題が発生する。実施の形態６は、このような課題を解決するためのものである。
図１８で説明した実施の形態５の通信装置においては、暗号通信に先立つ前処理、すなわち各種暗号通信にかかわるパラメータのネゴシエーションや共有鍵の交換の処理に無視できない時間がかかる場合には、予約した時間どおりに暗号通信を開始できないという問題が発生する。実施の形態６は、このような課題を解決するためのものである。
本実施の形態では、図２０の暗号処理使用資源表７６に、図２４に示すように、前処理命令数の欄をさらに設け、各暗号アルゴリズム毎に、前処理に必要なＣＰＵ処理量を実行命令数Ｉｍ（単位ＭＩ：メガインストラクション）として記載しておく。この数値は、予め通信装置の製造あるいは出荷時に記憶しておいてもよいし、前回に前処理を行なったときにＣＰＵの実行命令数を計測しておき、これを記憶するようにしてもよい。計測する場合は、リソース監視部８２において計測を行ない、計測結果を資源情報として暗号処理使用資源表７６に記憶する。実施の形態５のイベント・使用資源表６８作成時に、暗号通信タスクｂの開始イベント以前の時間帯における（許容ＣＰＵ処理能力−使用資源合計）＝ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）を算出し、Ｍｔ（秒）＝Ｉｍ／Ｙｃｐｕを求めると、前処理に必要な時間が求まる。
なお、共有鍵の処理には、相手機器の処理時間と通信時間も必要である。相手機器の処理時間が無視できる場合は、上記計算値に余裕値αを加算した値を前処理に必要な時間としてもよい。相手機器の処理時間が無視できない場合は、この処理時間も考慮しなければならない。相手機器での処理時間が本装置の処理時間とほぼ同等の場合は、Ｍｔ＝（Ｉｍ／Ｙｃｐｕ）×２＋β（βは通信時間および余裕時間）とすればよい。また、前回の暗号通信時の処理時間を記憶しておいて、本装置と相手機器の処理時間の合計値に余裕時間を加算したものをＭｔとしてもよい。本通信装置と同じように、相手機器のＣＰＵ処理能力が状況により変動するなどの理由により相手機器の処理時間が分からない場合は、相手機器に処理時間を問い合わせる処理を行った後にＭｔを決定すればよい。いずれにしても、前処理に必要な時間Ｍｔ＝Ｉｍ／Ｙｃｐｕ＋δ＋β（δは相手機器の処理時間）とすればよい。
Ｍｔが求まると、スケジュール部６４は、イベント・使用資源表６８のタスクｂの開始時刻をＭｔ（秒）だけ早める。このようにすれば、暗号通信アプリケーション７０のタスクｂは、１１：４５のＭｔ（秒）前に起動するから、前処理を完了するＭｔ（秒）後、すなわち１１：４５には暗号通信アプリケーション７０の暗号通信が実際に行なえるようになる。具体的には、タスクｂの開始イベント時刻よりもＭｔだけ早い時刻にタスクｂの前処理の開始を示すイベントを追加挿入しておき、スケジュール部６４が１１：４５のＭｔ（秒）前に前処理の開始を暗号処理部８０に指示するようにし、前処理が完了した１１：４５にタスクｂを起動するようにする。
本実施の形態によれば、暗号通信の前処理を行なうべき時間帯のＣＰＵ処理能力余裕値Ｙｃｐｕが少ない場合には、より早めに前処理を開始でき、暗号通信を予約時間通りに開始することが可能になる。
また、本実施の形態によれば、将来の動作を考慮して前もって共有鍵などの暗号・復号情報を用意できるため、必要なときにすぐに暗号通信を行なうことができる。また、資源の使用レベルが低いときに、共有鍵などの暗号・復号情報を用意しておける。
なお、ある暗号アルゴリズムを途中でいったん別の暗号アルゴリズムに切り替えてから再び元の暗号アルゴリズムを使用する場合に、暗号アルゴリズムを切り替える前に使用していた通信用の鍵を、当該別の暗号アルゴリズムの使用中も保持しておき、再び元の暗号アルゴリズムを使用するときにこの鍵を再利用するようにしてもよい。これにより、再び元の暗号アルゴリズムを使用する際の前処理を省略することができる。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
（実施の形態７）
つぎに、実施の形態７として、ひとつの暗号通信アプリケーションにおいて、許容ＣＰＵ処理能力Ｋｃｐｕ（ＭＩＰＳ）までの範囲で、暗号強度が最も大きい暗号アルゴリズムを切換選択して使用するようにした実施の形態について説明する。本実施の形態の構成は図１８と同様である。以下では、実施の形態５と異なる部分について説明する。
つぎに、実施の形態７として、ひとつの暗号通信アプリケーションにおいて、許容ＣＰＵ処理能力Ｋｃｐｕ（ＭＩＰＳ）までの範囲で、暗号強度が最も大きい暗号アルゴリズムを切換選択して使用するようにした実施の形態について説明する。本実施の形態の構成は図１８と同様である。以下では、実施の形態５と異なる部分について説明する。
図２１または図２２を参照すると、ＣＰＵ処理能力が許容ＣＰＵ処理能力Ｋｃｐｕ（ＭＩＰＳ）である５００ＭＩＰＳを超えない、すなわちＣＰＵ使用率が許容限界である５０％を超えない暗号アルゴリズムは、区間（１１：４５〜１２：００）と区間（１３：００〜未定）では３ＤＥＳ−ＣＢＣとＤＥＳ−ＣＢＣであるが、前者の方が暗号強度の順位が高い。スケジュール部６４は、図２２（１）および図２２（２）のイベント・使用資源表６８に基づいて、各イベント区間ごとに、使用資源合計が許容ＣＰＵ処理能力Ｋｃｐｕ（ＭＩＰＳ）＝５００ＭＩＰＳを超えない暗号アルゴリズムを暗号情報決定部７４に通知する。暗号情報決定部７４は、通知された暗号アルゴリズムが複数ある場合には暗号強度が最も大きいものを選択し、選択した暗号アルゴリズムをスケジュール部６４に通知する。イベント・使用資源表６８には、イベント時刻毎かつ暗号アルゴリズム毎に、その暗号アルゴリズムが選択されたかどうかを示す選択記入欄（図示せず）が新たに設けられ、スケジュール部６４は、暗号情報決定部７４から通知された暗号アルゴリズムの選択記入欄に、その暗号アルゴリズムが選択されたことを示す選択コードを記入する。つぎに、スケジュール部６４は、実施の形態６の場合と同様に、暗号アルゴリズムを切換えるべきイベント時刻の前の時間帯における（許容ＣＰＵ処理能力−使用資源合計）＝ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）を算出し、Ｍｔ（秒）＝Ｉｍ／Ｙｃｐｕを求め、このイベント時刻のＭｔ（秒）前に、前処理のイベントを挿入する。このようなイベント・使用資源表６８（ＤＥＳ−ＣＢＣに対応するものと、３ＤＥＳ−ＣＢＣに対応するものの両方）を作成した後、スケジュール部６４は、このイベント・使用資源表６８を参照しながら、各アプリケーションや、次に使用する暗号アルゴリズムの前処理および暗号処理などの起動・実行・停止の制御を行なう。このとき、スケジュール部６４は、イベント・使用資源表６８の上記選択記入欄の選択コードを参照して、選択された暗号アルゴリズムの前処理と、暗号化・復号化の処理を、暗号処理部８０に行なわせる。
図２５は、実施の形態７で用いられるイベント・使用資源表６８の一例である。イベント時刻欄には、年月日時刻の内、少なくとも時刻が記載される。タスク／資源欄には、予定タスク名と使用資源量（ＭＩＰＳ）が記載される。使用資源量（ＭＩＰＳ）は平均使用ＣＰＵ資源の量である。タスク／資源欄は、予約アプリケーションが増えると、必要に応じて増設される。暗号／資源欄には、候補暗号アルゴリズム名と使用資源量（ＭＩＰＳ）が記載される。資源合計欄には、予定タスクと候補暗号アルゴリズムによる使用資源合計（ＭＩＰＳ）が記載される。暗号／資源欄と資源合計欄は、候補暗号アルゴリズムの数だけ設けられる。
使用暗号欄には、使用資源合計が許容ＣＰＵ処理能力を超えない範囲で、暗号強度が最も高い暗号アルゴリズム名が記載される。この処理は次のように行なえばよい。スケジュール部６４が、各イベント区間毎に、使用資源合計が許容ＣＰＵ処理能力を超えないような候補暗号アルゴリズムを暗号情報決定部７４に通知する。暗号情報決定部７４は、図２０の暗号処理使用資源表７６を参照して、通知された候補暗号アルゴリズムの中から暗号強度が最も高いものを選択し、その暗号アルゴリズム名をスケジュール部６４に通知する。スケジュール部６４は、通知された暗号アルゴリズム名を使用暗号欄に記載する。
以上のように、本実施の形態によれば、使用ＣＰＵ資源量が許容ＣＰＵ処理能力を超えないような、かつ暗号強度が最も高い暗号アルゴリズムを、イベント区間毎に選択することができるため、ＣＰＵの使用率の変化に応じて、随時最適な暗号アルゴリズム使用することができる。
イベント・使用資源表６８は図２５の例に限らない。例えば、図２６の暗号アルゴリズムの欄のように、暗号アルゴリズム名と資源の量とを別の欄に記載するようにしてもよい。
（実施の形態８）
次に、実施の形態８として、前述した実施の形態７と実施の形態６を組み合わせた実施の形態について説明する。つまり本実施の形態は、実施の形態７において、暗号通信の前処理に無視できない時間がかかる場合に対処するために実施の形態６と同様に前処理を早めに行なうようにしたものである。
次に、実施の形態８として、前述した実施の形態７と実施の形態６を組み合わせた実施の形態について説明する。つまり本実施の形態は、実施の形態７において、暗号通信の前処理に無視できない時間がかかる場合に対処するために実施の形態６と同様に前処理を早めに行なうようにしたものである。
図２７は、本実施の形態で使用されるイベント・使用資源表６８の一例である。つまり、図２５に示したイベント・使用資源表６８に対して前処理欄と前処理暗号欄が新たに追加されている。前処理欄には、実施の形態７において説明した、前処理にかかる時間Ｍｔ（秒）＝Ｉｍ／Ｙｃｐｕが記載される。前処理暗号欄には、前処理の対象となる暗号アルゴリズム名が記載される。なお、前処理欄は必要がなければ省略してもよい。
つぎに、図２５のイベント・使用資源表６８から図２７のイベント・使用資源表６８を作成する手順について説明する。最初に使用する予定の暗号アルゴリズム３ＤＥＳ−ＣＢＣについて、１１：４５の直前の状態に基づいてＭｔ（秒）＝Ｉｍ／Ｙｃｐｕを計算する。この計算結果がＭｔ＝１８０（秒）であったとする。１１：４５よりＭｔだけ前には前処理を開始する必要があるため、１１：４５の１８０秒前、すなわち１１：４２のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にＭｔ１＝１８０を記載し、前処理暗号欄に３ＤＥＳ−ＣＢＣの略号３Ｄを記載する。
１２：００には暗号アルゴリズムがＤＥＳ−ＣＢＣに切り替わるので、この直前の状態に基づいてＭｔ（秒）を計算する。この計算結果がＭｔ＝１２０（秒）であったとする。１２：００までには前処理を完了する必要があるので、１２：００の１２０秒前、すなわち１１：５８のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にＭｔ２＝１２０を記載し、前処理暗号欄にＤＥＳ−ＣＢＣの略号Ｄを記載する。
１３：００には暗号アルゴリズムが３ＤＥＳ−ＣＢＣに切り替わるので、この直前の状態に基づいてＭｔ（秒）を計算する。この計算結果がＭｔ＝２２５（秒）であったとする。１３：００までには前処理を完了する必要があるので、１３：００の２２５秒＝３．７５分＝約４分前（１５秒は余裕分である。）、すなわち１１：５６のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にＭｔ３＝２２５を記載し、前処理暗号欄に３ＤＥＳ−ＣＢＣの略号３Ｄを記載する。
挿入された行の、タスク／資源、暗号／資源、資源合計の欄にはそれぞれ、その上段の内容をコピーして記載する。
このようにして作成したイベント・使用資源表６８を使用して、スケジュール部６４は、タスクａ〜ｃ、暗号処理の前処理、暗号処理の、起動・制御・停止を行なう。その結果、暗号アルゴリズムの使用前に前処理を完了できるので、予約時間通りに暗号通信アプリケーション（例えばカメラアプリケーション）を開始できる。
本実施の形態の場合、暗号処理部８０として、ある暗号アルゴリズムの実行と別の暗号アルゴリズムの前処理とを並行して実行できるものを設けておく。
ところで、前処理を行なうべき時間帯において他のタスクの追加や停止が行われる場合は、ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）が一定値ではなく変動するから、Ｍｔ（秒）を単純にＩｍ／Ｙｃｐｕにより求めることができない。そこで、このような場合には、前処理を完了しておくべき時刻から時間をさかのぼる方向へＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）の積分値を求めてゆき、積分値が前処理に必要なＣＰＵ処理の実行命令数Ｉｍ（単位ＭＩ：メガインストラクション）になる時間長をＭｔ（秒）として採用すればよい。この場合、イベント・使用資源表６８には、新たなイベント時刻欄を有する行が、暗号アルゴリズムの使用開始や切り換えの直前ではなく、いくつか上段の行の直前に挿入されることになる。
なお、上記図２７のイベント・使用資源表６８では、１２：５６に次に使用する３ＤＥＳ−ＣＢＣのための前処理を行なうようにしたが、１２：００に３ＤＥＳ−ＣＢＣからＤＥＳ−ＣＢＣに変更した後も３ＤＥＳ−ＣＢＣの公開鍵、秘密鍵などを破棄せず３ＤＥＳ−ＣＢＣを再度使用できる状態としておき、１２：５６から設定した前処理を行なわないようにしてもよい。このようにすれば、前処理の再実行によるＣＰＵ資源の消費を削減できる。
（実施の形態９）
次に、実施の形態９として、実施の形態８において候補暗号アルゴリズムが３つに増えた場合の例を説明する。図２８および図２９は、候補暗号アルゴリズムとして、ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）が用意されている場合のイベント・使用資源表６８と暗号処理使用資源表７６の例である。ＡＥＳは、平均使用ＣＰＵ資源量が多くない割に暗号強度が大きく、３つの暗号アルゴリズムの中では暗号強度が１位である。イベント・使用資源表６８では、３つの候補暗号アルゴリズムに対応して、それぞれ資源合計が計算される。１１：４５のイベント時刻を例にとると、許容ＣＰＵ処理能力５００（ＭＩＰＳ）を超えない暗号アルゴリズムは、ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ、ＡＥＳである。スケジュール部６４は、この３つを候補として暗号情報決定部７４に通知する。また、図１９のスケジュール・使用資源表６６では、１１：４５開始のタスクｂで使用する暗号アルゴリズムは暗号強度が第３位以上のものとする条件がついている。この情報もスケジュール部６４から暗号情報決定部７４に通知される。暗号情報決定部７４は、図２９の暗号処理使用資源表７６を参照して、３つの暗号アルゴリズムの中から暗号強度が第３位以上のもので、かつその中で暗号強度順位が最も高いもの（ここではＡＥＳ）を選択し、スケジュール部６４に通知する。そして、スケジュール部６４は、使用暗号欄の１１：４５イベント時刻の欄にＡＥＳ（略号Ａ）を記入する。
次に、実施の形態９として、実施の形態８において候補暗号アルゴリズムが３つに増えた場合の例を説明する。図２８および図２９は、候補暗号アルゴリズムとして、ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）が用意されている場合のイベント・使用資源表６８と暗号処理使用資源表７６の例である。ＡＥＳは、平均使用ＣＰＵ資源量が多くない割に暗号強度が大きく、３つの暗号アルゴリズムの中では暗号強度が１位である。イベント・使用資源表６８では、３つの候補暗号アルゴリズムに対応して、それぞれ資源合計が計算される。１１：４５のイベント時刻を例にとると、許容ＣＰＵ処理能力５００（ＭＩＰＳ）を超えない暗号アルゴリズムは、ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ、ＡＥＳである。スケジュール部６４は、この３つを候補として暗号情報決定部７４に通知する。また、図１９のスケジュール・使用資源表６６では、１１：４５開始のタスクｂで使用する暗号アルゴリズムは暗号強度が第３位以上のものとする条件がついている。この情報もスケジュール部６４から暗号情報決定部７４に通知される。暗号情報決定部７４は、図２９の暗号処理使用資源表７６を参照して、３つの暗号アルゴリズムの中から暗号強度が第３位以上のもので、かつその中で暗号強度順位が最も高いもの（ここではＡＥＳ）を選択し、スケジュール部６４に通知する。そして、スケジュール部６４は、使用暗号欄の１１：４５イベント時刻の欄にＡＥＳ（略号Ａ）を記入する。
（実施の形態１０）
Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換やＩＫＥによる共有鍵の交換では、共有鍵の寿命を設定することができるようになっている。ひとつの鍵を長時間使用すると、その間に鍵を盗まれて解読される危険性が増える。このため、新たな鍵、すなわち更新鍵を作成しておき、適切な時間後には更新鍵に切り替えるようにする方式が有効である。このような鍵の寿命を設ける方式では、鍵の寿命が満了になる前に、次に使用する更新鍵の生成を完了しておく必要がある。更新鍵の生成を行なうことをリキー処理と呼ぶ。最初の鍵の生成、リキー処理の両方とも、鍵の生成には暗号化や復号化と同様に大きなＣＰＵ処理能力を必要とする場合が多い。したがって、鍵寿命満了時刻よりも充分前の時刻にリキー処理を開始することが望まれる。しかしながら、リキー処理を行なうべき時間帯に大きなＣＰＵ処理能力を消費するアプリケーションがあると、ＣＰＵの処理負荷が許容ＣＰＵ処理能力を超えてしまい、更新鍵の準備が間に合わなくなる。
Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換やＩＫＥによる共有鍵の交換では、共有鍵の寿命を設定することができるようになっている。ひとつの鍵を長時間使用すると、その間に鍵を盗まれて解読される危険性が増える。このため、新たな鍵、すなわち更新鍵を作成しておき、適切な時間後には更新鍵に切り替えるようにする方式が有効である。このような鍵の寿命を設ける方式では、鍵の寿命が満了になる前に、次に使用する更新鍵の生成を完了しておく必要がある。更新鍵の生成を行なうことをリキー処理と呼ぶ。最初の鍵の生成、リキー処理の両方とも、鍵の生成には暗号化や復号化と同様に大きなＣＰＵ処理能力を必要とする場合が多い。したがって、鍵寿命満了時刻よりも充分前の時刻にリキー処理を開始することが望まれる。しかしながら、リキー処理を行なうべき時間帯に大きなＣＰＵ処理能力を消費するアプリケーションがあると、ＣＰＵの処理負荷が許容ＣＰＵ処理能力を超えてしまい、更新鍵の準備が間に合わなくなる。
そこで、本実施の形態１０においては、鍵を更新するまでの鍵寿命の値と予約スケジュールに基く使用資源合計値の推移とを考慮して、適切なリキー処理開始時刻をイベント・使用資源表６８にイベントとして追加する。
まず、暗号処理使用資源表７６に鍵寿命時間の欄を設け、各暗号アルゴリズム毎に、設定する予定の鍵寿命時間Ｊｔを記載する。なお、一般的には、全体の危険度を一定とするためには、アルゴリズムの暗号強度が高いほど鍵の寿命を長くすることができる。暗号アルゴリズム使用の開始時刻をＣｔとし、最初の鍵の使用開始時刻をＫｔ１とすると、最初の鍵の使用開始時刻はＫｔ１＝Ｃｔであり、鍵の寿命満了時刻は（Ｃｔ＋Ｊｔ）である。時刻（Ｃｔ＋Ｊｔ）の前の時間帯でのＣＰＵ処理能力余裕値をＹｃｐｕ（ＭＩＰＳ）とし、リキー処理に必要なＣＰＵ命令数をＩｒ（単位ＭＩ：メガインストラクション）とすると、リキー処理に必要な時間はＲｔ＝Ｉｒ／Ｙｃｐｕである。時刻（Ｃｔ＋Ｊｔ−Ｒｔ）までにリキー処理を開始すれば、鍵の寿命満了時刻（Ｃｔ＋Ｊｔ）までに更新鍵を準備できる。
なお、ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）が、リキー処理予定の時間帯において一定値ではなく変動する場合は、実施の形態８における前処理の場合と同様の考え方により、リキー処理を完了しておくべき時刻（Ｃｔ＋Ｊｔ）から時間をさかのぼる方向へＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）の積分値を求めてゆき、積分値がリキー処理に必要なＣＰＵ処理の実行命令数Ｉｒになる時間長をＲｔとして採用すればよい。
つぎに、リキー処理開始時刻（Ｃｔ＋Ｊｔ−Ｒｔ）をイベント時刻としたリキー処理イベントの行をイベント・使用資源表６８に挿入することによって、リキー処理をスケジュールに記入する。この操作は、暗号通信の前処理で説明したのと同様の操作を、スケジュール部６４と暗号情報決定部７４の間で行なえばよい。
次の更新鍵の寿命に対しては、鍵の寿命満了時刻が（Ｃｔ＋２＊Ｊｔ）となるので、この時刻に対するリキー処理開始時刻を求め、追加イベントを設ければよい。同様の操作を、暗号アルゴリズムの使用終了予定のイベント時刻まで行なう。
以上のように、本実施の形態弐よれば、予定されるＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）に応じたリキー処理の計画を予め立てられるので、リキー処理時に許容ＣＰＵ処理能力を超過してシステムが破綻することが無くなる。
なお、Ｒｔは、若干の余裕を持たせるために一定時間分αだけ長めにするのが安全である。
鍵の寿命を管理する場合、一般的には、
（１）時間で管理する手法（例えば、鍵の寿命を、鍵を生成してからの経過時間（Ｘ秒）や鍵の使用を開始してからの経過時間（Ｙ秒）により規定する手法）
（２）データ転送量で管理する手法（例えば、鍵の寿命を、処理パケット数（ｍパケット）や処理バイト数（ｎバイト）により規定する手法）
などの手法があるが、本実施の形態は、（１）の手法のうち、鍵の使用を開始してからの経過時間により鍵の寿命が規定されている場合に簡単に適用できる。鍵を生成してからの経過時間により鍵の寿命が規定されている場合には、以下のような工夫をすればよい。鍵の生成時刻は、本通信装置と通信相手の機器とで同じ時刻でない場合がある。すなわち、鍵の生成においては、一般的に、相手から公開値を受け取ってから自分の秘密鍵を生成するため、一方の鍵の寿命満了時刻は、公開値を受け取ってから自分の秘密鍵を生成するための時間分だけ遅くなる。この時間関係は、鍵の生成を起動する側の機器と、鍵の生成手順により決まる。このように一方の鍵の生成が他方よりも遅れる場合、早く生成される側の鍵の生成時刻を起点としてＪｔを鍵の寿命とすれば、時間Ｊｔの間は、両方の鍵が寿命時間内になり、一方の鍵の寿命が寿命満了になることはない。また、本装置と相手機器とが通信により、双方の鍵の生成が完了したことを知ることができる場合は、その時点を鍵の寿命起算の時点とすればよく、双方の鍵の寿命満了時刻は一致する。
（１）時間で管理する手法（例えば、鍵の寿命を、鍵を生成してからの経過時間（Ｘ秒）や鍵の使用を開始してからの経過時間（Ｙ秒）により規定する手法）
（２）データ転送量で管理する手法（例えば、鍵の寿命を、処理パケット数（ｍパケット）や処理バイト数（ｎバイト）により規定する手法）
などの手法があるが、本実施の形態は、（１）の手法のうち、鍵の使用を開始してからの経過時間により鍵の寿命が規定されている場合に簡単に適用できる。鍵を生成してからの経過時間により鍵の寿命が規定されている場合には、以下のような工夫をすればよい。鍵の生成時刻は、本通信装置と通信相手の機器とで同じ時刻でない場合がある。すなわち、鍵の生成においては、一般的に、相手から公開値を受け取ってから自分の秘密鍵を生成するため、一方の鍵の寿命満了時刻は、公開値を受け取ってから自分の秘密鍵を生成するための時間分だけ遅くなる。この時間関係は、鍵の生成を起動する側の機器と、鍵の生成手順により決まる。このように一方の鍵の生成が他方よりも遅れる場合、早く生成される側の鍵の生成時刻を起点としてＪｔを鍵の寿命とすれば、時間Ｊｔの間は、両方の鍵が寿命時間内になり、一方の鍵の寿命が寿命満了になることはない。また、本装置と相手機器とが通信により、双方の鍵の生成が完了したことを知ることができる場合は、その時点を鍵の寿命起算の時点とすればよく、双方の鍵の寿命満了時刻は一致する。
なお、上記説明では、本通信装置側の処理時間だけを考慮する場合を例として説明したが、共有鍵の処理には相手機器の処理時間と通信時間も必要である。これらを考慮するためには、前処理での相手機器における鍵の生成処理時間を記憶しておいて、これに本通信装置での上記Ｒｔ＝Ｉｒ／Ｙｃｐｕに余裕時間を加算したものをＲｔとすればよい。ただし、相手機器の処理時間が無視できる場合には、Ｉｒ／Ｙｃｐｕに単に余裕値αを加算した値をＲｔとしてもよい。また、相手機器での処理時間が本通信装置の処理時間とほぼ同等の場合には、Ｒｔ＝（Ｉｒ／Ｙｃｐｕ）×２＋β（βは通信時間および余裕時間）とすればよい。本装置の場合と同様に、相手機器でも、他の一般的なアプリケーションにより処理時間が変わる可能性がある場合は、相手機器に処理時間を問い合わせる処理を行った後にＲｔを決定すればよい。いずれにしても、Ｒｔ＝Ｉｒ／Ｙｃｐｕ＋δ＋β（δは相手機器での処理時間）とすればよい。
すでに説明したように、リキー処理においては、暗号アルゴリズム使用の開始時刻Ｃｔを起点として、鍵の寿命満了時刻（Ｃｔ＋Ｊｔ＊ｎ）までに更新鍵の生成を完了しなければならない。更新鍵の生成を前の鍵の寿命満了までに確実に行なうための余裕を確保するためにリキー処理を少し早めに開始すると、その分、鍵が早めに生成される。この鍵の寿命がＪｔであると、本来予定されていた次の鍵の寿命満了時刻（Ｃｔ＋Ｊｔ＊（ｎ＋１））よりも早くこの鍵の寿命が満了するおそれがある。このようなことを避けるには、リキー処理において設定する鍵寿命を、スケジュール上の鍵更新の時間間隔よりも少し長めにすればよい。
（実施の形態１１）
つぎに、実施の形態１１として、イベント・使用資源表６８から予定されるＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）の推移に応じて、鍵の寿命値を適切に設定する実施の形態について説明する。
つぎに、実施の形態１１として、イベント・使用資源表６８から予定されるＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）の推移に応じて、鍵の寿命値を適切に設定する実施の形態について説明する。
スケジュール部６４と暗号情報決定部７４が、使用する暗号アルゴリズムを選択した段階で、スケジュール部６４は、スケジュール・使用資源表６６および暗号処理使用資源表７６を参照して、あるいはイベント・使用資源表６８を参照して、暗号アルゴリズム使用開始時刻Ｃｔの前の時間帯におけるＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）を調べる。そして、リキー処理に必要な時間Ｒｔ＝Ｉｒ／Ｙｃｐｕを求め、さらに（Ｒｔ＋α）を計算し、この値を鍵の寿命として暗号情報決定部７４に通知する。なお、αは余裕値である。よって、鍵の寿命満了時刻は（Ｃｔ＋Ｒｔ＋α）になる。つぎに、（Ｃｔ＋Ｒｔ＋α）の前の時間帯におけるＣＰＵ処理能力余裕値を調べ、リキー処理に必要な時間を計算し、次の更新鍵の寿命とする。このような処理を繰り返し、各リキー処理の開始時刻をイベントに追加する。鍵の寿命完了と同時に、リキー処理を開始し、リキー処理完了時に、新たに生成した鍵を即座に使用開始することができる。
このようにすれば、ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）を有効に使用して、早めにリキー処理が行なえるので、鍵の寿命も短くでき、暗号通信の安全性を高く保てる。
また、ＣＰＵ処理能力余裕値Ｙｃｐｕ（ＭＩＰＳ）の一部分のみを使用するようにすれば、リキー処理時間は長くかかり、その分だけ鍵の寿命時間を長くする必要があるが、かわりに、ＣＰＵ処理能力に余裕を残せる。
本実施の形態によれば、上記のように柔軟な処理を計画的に組み立てることができる。
本実施の形態は、鍵の寿命を時間で管理する手法の場合に適用するのが好ましい。
（実施の形態１２）
図２７を参照して説明した実施の形態８や、図２８および図２９を参照して説明した実施の形態９では、共有鍵を交換する前処理を、暗号アルゴリズムを使用する直前、および暗号アルゴリズムを切り替える直前に行なった。しかしながら、ひとつの暗号通信アプリケーションにおいて複数の暗号アルゴリズムを切り替えて使用する場合には、暗号通信アプリケーションを開始する前に、必要な複数の共有鍵をまとめて生成するようにしてもよい。この場合、図２７を例に取れば、前処理のＭｔ１、Ｍｔ２、Ｍｔ３を１１：４５までに順番に実行するようなイベントを挿入すればよい。
図２７を参照して説明した実施の形態８や、図２８および図２９を参照して説明した実施の形態９では、共有鍵を交換する前処理を、暗号アルゴリズムを使用する直前、および暗号アルゴリズムを切り替える直前に行なった。しかしながら、ひとつの暗号通信アプリケーションにおいて複数の暗号アルゴリズムを切り替えて使用する場合には、暗号通信アプリケーションを開始する前に、必要な複数の共有鍵をまとめて生成するようにしてもよい。この場合、図２７を例に取れば、前処理のＭｔ１、Ｍｔ２、Ｍｔ３を１１：４５までに順番に実行するようなイベントを挿入すればよい。
このように、早めに鍵を生成する場合は、鍵の寿命は、
（１）使用開始からＪ秒後
（２）使用開始からｍパケット処理後
（３）使用開始からｎバイト処理後
などと規定するのがよい。鍵の寿命を鍵の生成からの経過時間で規定する必要がある場合には、上記（１）の時間に、生成以降実際に鍵を使用するまでの時間を加算したものを寿命時間として設定すればよい。
（１）使用開始からＪ秒後
（２）使用開始からｍパケット処理後
（３）使用開始からｎバイト処理後
などと規定するのがよい。鍵の寿命を鍵の生成からの経過時間で規定する必要がある場合には、上記（１）の時間に、生成以降実際に鍵を使用するまでの時間を加算したものを寿命時間として設定すればよい。
（実施の形態１３）
予めスケジュールで「暗号通信アプリケーションを開始してからａ秒後に処理負荷が高くなる」と予測される場合に、その暗号通信アプリケーションの開始前に実行される前処理において、予め高強度・高負荷の暗号アルゴリズムと低強度・低負荷の暗号アルゴリズムの両方の鍵を用意しておき、スケジュールで全体処理負荷が高くなると予測される時点で、暗号アルゴリズムを高強度・高負荷のものから低強度・低負荷のものに切り替える方式を取るようにしてもよい。この場合、暗号アルゴリズムを低強度・低負荷のものに切り替えた後に、高強度・高負荷のアルゴリズムの鍵情報を明示的に削除することで、メモリ資源の浪費の低減を図ることが可能である。
予めスケジュールで「暗号通信アプリケーションを開始してからａ秒後に処理負荷が高くなる」と予測される場合に、その暗号通信アプリケーションの開始前に実行される前処理において、予め高強度・高負荷の暗号アルゴリズムと低強度・低負荷の暗号アルゴリズムの両方の鍵を用意しておき、スケジュールで全体処理負荷が高くなると予測される時点で、暗号アルゴリズムを高強度・高負荷のものから低強度・低負荷のものに切り替える方式を取るようにしてもよい。この場合、暗号アルゴリズムを低強度・低負荷のものに切り替えた後に、高強度・高負荷のアルゴリズムの鍵情報を明示的に削除することで、メモリ資源の浪費の低減を図ることが可能である。
なお、鍵の寿命は通信相手と取り決めるのが一般であり、鍵を削除する場合は、その旨を通信相手に通知する必要があるので、そのための通信処理負荷が発生する。このような処理負荷も、スケジュール・使用資源表６６およびイベント・使用資源表６８に反映させてもよい。
なお、予め高強度・高負荷の暗号アルゴリズムの鍵の寿命を、全体処理負荷が高くなる時点まで（あるいはその前後まで）としておき、鍵の削除の通知の手順を省略するようにしてもよい。
（実施の形態１４）
上記各実施の形態では、使用資源として、ＣＰＵ処理能力（ＭＩＰＳ）に着目し、許容資源使用量である許容ＣＰＵ処理能力の範囲でのＣＰＵの有効利用と、システムの破綻の防止を行なうようにした。しかしながら、通信装置の資源としては、この他に、使用メモリサイズ（ＭＢ）や内部バスラインの時間占有率（％）などがある。例えば、使用メモリサイズがシステムのＲＡＭサイズ（たとえば、５２１ＭＢ）を超えると、ＨＤＤへの待避が頻繁に起こり、一部のアプリケーションが予約通りに実行できなかったり、サービスが一時止まってしまうなどの不具合が発生する。また、内部バスラインの時間占有率（％）が１００％を超えても同様の事態が起きる。使用資源、すなわち平均の使用メモリサイズや内部バスラインの平均時間占有率を、最大値に対して例えば５０％程度の許容資源使用量に押さえるようにすれば、不具合の発生は実質上回避できる。
上記各実施の形態では、使用資源として、ＣＰＵ処理能力（ＭＩＰＳ）に着目し、許容資源使用量である許容ＣＰＵ処理能力の範囲でのＣＰＵの有効利用と、システムの破綻の防止を行なうようにした。しかしながら、通信装置の資源としては、この他に、使用メモリサイズ（ＭＢ）や内部バスラインの時間占有率（％）などがある。例えば、使用メモリサイズがシステムのＲＡＭサイズ（たとえば、５２１ＭＢ）を超えると、ＨＤＤへの待避が頻繁に起こり、一部のアプリケーションが予約通りに実行できなかったり、サービスが一時止まってしまうなどの不具合が発生する。また、内部バスラインの時間占有率（％）が１００％を超えても同様の事態が起きる。使用資源、すなわち平均の使用メモリサイズや内部バスラインの平均時間占有率を、最大値に対して例えば５０％程度の許容資源使用量に押さえるようにすれば、不具合の発生は実質上回避できる。
使用メモリサイズや内部バスラインの時間占有率（％）の合計値についても、上記したスケジュール・使用資源表６６やイベント・使用資源表６８を作成し、許容値を超えない暗号アルゴリズムを選択するようにすることができる。
また、ＣＰＵ処理能力、使用メモリサイズ、バスラインの時間使用率の３つの要素のうちのいずれか１つだけでなく、２つあるいは３つの要素を加味した総合的使用率に基づいて暗号アルゴリズムの選択を行なうようにしてもよい。総合的使用率は、一例として、個々の要素の使用率に所定の重みを掛けた加重平均値で表すことができる。
（実施の形態１５）
上記各実施の形態では、リモコン１０２や外部からアプリケーションの実行を予約する。外部からの予約は、携帯型の情報機器や携帯電話からインターネット回線網を介して行なわれることが想定される。
上記各実施の形態では、リモコン１０２や外部からアプリケーションの実行を予約する。外部からの予約は、携帯型の情報機器や携帯電話からインターネット回線網を介して行なわれることが想定される。
図１８や図２３の構成において、スケジュール登録用の専用のアプリケーションをさらに設けておき、そこで予約要求を受け付け、この予約要求をスケジュール部６４に通知し、スケジュール部６４がこの予約要求をスケジュール・使用資源表６６に反映させる方法をとることができる。また、各アプリケーションが、予約要求のうち自アプリケーションに関係したもののみを一旦受付け、そしてスケジュール部６４に登録を要求する方法もとれる。後者の方法では、アプリケーション特有の形式で登録することができる。
（実施の形態１６）
図３０は、上記実施の形態５〜１５で説明した通信装置で用いられるアルゴリズム選択方法の基本的な手順を示すフローチャートである。なお、フローチャートの各手順は、基本的には通信装置のＣＰＵ９４によってプログラムに従って実行される。
図３０は、上記実施の形態５〜１５で説明した通信装置で用いられるアルゴリズム選択方法の基本的な手順を示すフローチャートである。なお、フローチャートの各手順は、基本的には通信装置のＣＰＵ９４によってプログラムに従って実行される。
まず、通信装置は、ステップＳ３０００の予約登録手順において、アプリケーションの予約を受付け、スケジュール登録する。この登録は、基本的には仮の登録である。ステップＳ３００１の平均使用ＣＰＵ資源合計値算出手順において、受け付けたアプリケーションが暗号通信を行なうものかどうか判定し、暗号通信を行なうものである場合は、それまでに受け付けている他のアプリケーションも含めて、平均使用ＣＰＵ資源の合計値を算出する。この処理は、複数用意されている暗号アルゴリズムのそれぞれについて行われる。そして、スケジュールのどの時点でも許容ＣＰＵ処理能力を超えることがないような暗号アルゴリズムを一次選択する。ステップＳ３００２の暗号アルゴリズム選択手順において、一次選択された暗号アルゴリズムの中から必要暗号強度の条件に合致する暗号アルゴリズムを選択する。ステップＳ３００３のスケジュール登録手順において、選択した暗号アルゴリズムの処理をスケジュールに登録する。
なお、上記ステップＳ３００１において、スケジュールのどのイベント区間でも許容ＣＰＵ処理能力を超えることがない暗号アルゴリズムを一次選択するのではなく、各イベント区間毎に許容ＣＰＵ処理能力を超えることがない暗号アルゴリズムを一次選択し、ステップＳ３００２において、一次選択された暗号アルゴリズムの中から、必要暗号強度の条件に合致する暗号アルゴリズムを各イベント区間ごとに選択するようにしてもよい。このようにすれば、ＣＰＵ処理能力に余裕がある区間においては暗号強度がより高い暗号アルゴリズムを選択できる可能性が高まる。
上記各ステップにおいて、平均使用ＣＰＵ資源合計値が許容ＣＰＵ処理能力を越えてしまう場合や、ステップＳ３００２において所定条件に合致する暗号アルゴリズムがない場合には、アプリケーションの予約ができないので、その旨を予約の要求元（典型的にはユーザ）に対して通知（回答、表示）する。
なお、上記のようにアプリケーションの予約ができない状況が発生したときに、予約の要求元に対してスケジュール情報を掲示し、仮登録された、あるいは既に予約登録済の暗号通信アプリケーションの暗号アルゴリズムの変更を要求元が行なうことができるようにして特定の予約を優先させることも可能である。また、仮登録された、あるいは既に予約登録済の暗号通信アプリケーションの暗号アルゴリズムのうち、最も処理負荷の高いもの、あるいは最も暗号強度の高いものから順に、暗号アルゴリズムの再選択（より暗号強度の低いものに選択しなおす）を仮に行ない（平均使用ＣＰＵ資源合計値の再計算を含む）、その結果、新規暗号通信アプリケーションの登録が可能と判断された場合に、上記暗号アルゴリズムの再選択を実際に行なった上で新規暗号通信アプリケーションの登録を行なうことも可能である。このとき、必要ならば、図１９において説明した必要暗号強度の条件を緩くして、暗号強度の低い暗号アルゴリズムを新たに選択対象に追加した上で、暗号アルゴリズムの再選択を行ってもよい。また、暗号アルゴリズムを選択できなかったイベント区間に対して、必要暗号強度の条件を緩くした上で、その結果として選択可能となった暗号アルゴリズムの中からより暗号強度の高いものを選択するようにしてもよい。また、このような登録内容の変更は、自動的に行なえるようにしてもよいし、予約要求元による選択指示に基づいて、上記方法の選択や暗号アルゴリズム自体の選択などを行なえるようにしてもよい。
ただし、上記のように必要暗号強度の条件を緩めずに済む場合もある。すなわち、「必要暗号強度第３位以上」のような条件の下で暗号強度が第１位の暗号アルゴリズムが採用されて登録されていた場合には、この条件を緩めることなく、この暗号アルゴリズムをより暗号強度の低いもの（暗号強度が第２位または第３位のもの）に変更することで、新規暗号通信アプリケーションの暗号通信の予約、登録が可能となる場合もある。
また、暗号アルゴリズムの再選択とは別に、アプリケーションの種類によっては、一般のアプリケーションも含めて、その実行開始時刻をずらすことによって、新規要求アプリケーションの登録を可能とするようにしてもよい。また、暗号通信平均データ転送量を暗号通信アプリケーションによって制御できる場合には、その値を低くすることによって、平均使用ＣＰＵ資源合計値を低減し、新規要求アプリケーションの登録を可能とするようにしてもよい。また、これらの変更を予約要求元が行なう場合は、認証により、変更する権限を有する者のみが変更を許可されるようにしてもよい。
図３１は、図３０よりも更に詳しいフローチャートである。通信装置は、ステップＳ３１００において、アプリケーションの予約があった場合、その予約を受け付ける。ステップＳ３１０１において、スケジュール・使用資源表６６に予約を登録する。これは、仮登録である。ステップＳ３１０２において、スケジュール・使用資源表６６を元にイベント・使用資源表６８にイベントを追加する。ステップＳ３１０３において、仮登録された予約が暗号通信アプリケーションの予約かどうか判定する。この判定結果がＹＥＳなら、すでに登録されている各種アプリケーションに加えて、用意されている複数種の暗号アルゴリズムのそれぞれを使用した場合の平均使用ＣＰＵ資源の合計値を、各イベント区間について算出する。ステップＳ３１０５において、許容ＣＰＵ処理能力を超えないような暗号アルゴリズムを候補として一次選択する。ここで選択される暗号アルゴリズムの数は、複数、ひとつ、無しのいずれかとなる。ステップＳ３１０６において、候補暗号アルゴリズムが一つ以上あるかどうか判定し、この判定結果がＹＥＳなら、ステップＳ３１０７において、所定の条件を満たす暗号アルゴリズムを選択する。所定の条件とは図１９の必要暗号強度である。条件を満たす暗号アルゴリズムがあれば、ステップＳ３１０８においてＹＥＳと判定される。ステップＳ３１０９において、共有鍵交換などの前処理の開始時刻の算出を、実施の形態６で説明した方法により行なう。ステップＳ３１１０において、鍵の寿命満了に備えたリキー処理の開始時刻の算出を、実施の形態１０で説明した方法により行なう。ステップＳ３１１１において、選択した暗号アルゴリズムの使用時刻、前処理の実行時刻、リキー処理の開始時刻をスケジュールに登録する、すなわちイベント・使用資源表６８に挿入・追記する。ステップＳ３１１２において、イベント時刻まで待機する。次の予約に対して待機してもよい。イベント時刻が到来すれば、そのイベントを実行してゆく。
ステップＳ３１０３の判定結果がＮＯ、すなわち予約されたアプリケーションが暗号通信を伴わないものであれば、ステップＳ３１１３において、平均使用ＣＰＵ資源の合計値を各イベント区間に対して算出する。ステップＳ３１１４において、その合計値が許容ＣＰＵ処理能力未満かどうか判定し、この判定結果がＹＥＳであれば、ステップＳ３１０１、ステップＳ３１０２での登録は有効となる。ステップＳ３１１４の判定結果がＮＯであれば、ステップＳ３１０１、ステップＳ３１０２で登録したアプリケーションをステップＳ３１１５において消去する。さらにステップＳ３１１６において、「予約が不可能である。」、「予約を失敗した。」旨の通知を予約要求元に対して行なう。ステップＳ３１０６、ステップＳ３１０８の判定結果がＮＯの場合、使用可能な暗号アルゴリズムが見つからなかったので予約の登録は失敗し、ステップＳ３１１５、ステップＳ３１１６の処理を行なう。
図３２は、許容ＣＰＵ処理能力を超えてしまうためにそのままでは新たな予約を登録できない場合に、既存のアプリケーションのアルゴリズムを変更することによりＣＰＵ処理能力の余裕を生み出し、予約要求に応えるようにした処理方法の手順を示すフローチャートである。図３１のステップＳ３１０６、ステップＳ３１０８、ステップＳ３１１４の判定結果がＮＯ、すなわち暗号アルゴリズムが選択できなかった場合には、ステップＳ３２０１において、すでにスケジュールに登録済みの暗号通信アプリケーションのうち、最も負荷が高い暗号アルゴリズムを使用予定の暗号通信アプリケーションを検索する。ステップＳ３２０２において、その暗号アルゴリズムを負荷がより低いものに変更した場合の、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて使用資源合計を算出し、ステップＳ３２０３において、この算出結果が許容ＣＰＵ処理能力未満かどうか判定する。この判定結果がＹＥＳなら、暗号アルゴリズムの変更を確定し、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて、ステップＳ３１０９以降で、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップＳ３２０３の判定結果がＮＯ、すなわち許容ＣＰＵ処理能力がまだ不足であれば、ステップＳ３２０５において、暗号アルゴリズムの変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がＹＥＳならステップＳ３２０１に戻り、そのアプリケーションの暗号アルゴリズムの変更を試みる。ステップＳ３２０５の判定結果がＮＯなら、予約要求に対応することがまったく不可能であるので、ステップＳ３１１５に戻る。
図３３は、許容ＣＰＵ処理能力を超えてしまうためにそのままでは新たな予約を登録できない場合に、予約要求元（典型的にはユーザ）に予約の変更を促すように表示を行ない、予約要求元の判断により暗号アルゴリズムの再選択を行なうアルゴリズム選択方法の手順を示すフローチャートである。図３１のステップＳ３１０６、ステップＳ３１０８、ステップＳ３１１４の判定結果がＮＯ、すなわちアルゴリズムが選択できなかった場合には、ステップＳ３３００において、予約要求元に再選択を促す表示を行なう。予約要求元はその表示を見て、ステップＳ３３０１において、すでにスケジュールに登録済みの暗号通信アプリケーションのうち、最も負荷が高い暗号アルゴリズムを使用予定の暗号通信アプリケーションを検索し、選択する。通信装置は、その選択に応答して、ステップＳ３３０２において、その暗号アルゴリズムを負荷がより低いものに変更した場合の、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて使用資源合計を算出し、ステップＳ３３０３において、この算出結果が許容ＣＰＵ処理能力未満かどうか判定する。この判定結果がＹＥＳなら、暗号アルゴリズムの変更を確定し、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて、ステップＳ３１０９以降で、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップＳ３３０３の判定結果がＮＯ、すなわち許容ＣＰＵ処理能力がまだ不足であれば、ステップＳ３３０５において、暗号アルゴリズムの変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がＹＥＳならステップＳ３３００において、予約要求元に再選択を促す表示を行ない、ステップＳ３３０１以降、暗号アルゴリズム変更を試みる。ステップＳ３３０５の判定結果がＮＯなら、予約要求に対応することがまったく不可能であるので、ステップＳ３１１５に戻る。
なお、上記のような暗号アルゴリズムの再選択では、前述したように、必要暗号強度の条件を緩める場合や、必要暗号強度の条件を緩めずに済む場合がある。
図３３のフローチャートにおいて、ステップＳ３３０１では、ユーザである予約要求元に、暗号アルゴリズムを負荷がより低いものに変更する暗号通信アプリケーションを指定させ、ステップＳ３３０２において、指定された暗号アルゴリズムを負荷がより低いものに変更した場合の使用資源合計を算出するようにしてもよい。この場合、ステップＳ３３０１において、ユーザである予約要求元に、暗号アルゴリズムを変更可能な暗号通信アプリケーションがどれであるかを予約要求元が識別できるような情報、あるいは暗号アルゴリズムを変更可能な暗号通信アプリケーションの中から所望の暗号通信アプリケーションを予約要求元が選択できるような情報を提示するとともに、現在予約登録されている暗号アルゴリズムと、選択・変更可能な暗号アルゴリズム（すなわち変更対象候補となる暗号アルゴリズム）とを提示し、予約要求元に実際に暗号アルゴリズムの変更を実施するか否かを判定させ、変更する内容を決めさせるようにしてもよい。予約要求元に対して、さらに、どのような暗号アルゴリズムを適用可能かを示す情報、あるいはそれらの暗号アルゴリズムの暗号強度やその順位などの情報を表示・提供してもよい。これにより、予約要求元は、再選択するか否かの判断だけではなく、その内容までも考慮したうえでの判断を行なうことができるようになる。
（実施の形態１７）
これまでに、暗号通信アプリケーション、前処理、リキー処理などを予約登録や追加登録する場合について説明した。スケジュール部６４がイベントを実行している最中に新たな追加の予約登録の要求が発生した場合であっても、上記各実施の形態において説明した許容資源量の余裕の範囲であればイベントの追加が可能である。スケジュール部６４は、追加予約登録要求を受けると、この予約をスケジュール・使用資源表６６に仮登録し、作成済みのイベント・使用資源表６８に追加アプリケーションに関するタスク欄を設け、さらにその開始希望時刻に対応するイベント行と終了希望時刻に対応するイベント行を挿入した、仮のイベント・使用資源表を別途作成する。そして、挿入した開始希望時刻イベント行と終了希望時刻イベント行に、各々の上段の各タスクと暗号アルゴリズムの記載内容をそれぞれコピーする。そしてさらに、開始希望時刻イベント行から終了希望時刻イベント行の直前のイベント行までの各イベント行に、追加使用希望する使用資源量を追記する。それから、スケジュール部６４と暗号情報決定部７４は、使用資源量の合計の算定や、その合計と許容資源量との比較を行ない、その合計が許容資源量未満であれば、更に必要に応じて暗号アルゴリズムの選択などの作業を行なう。最終的に予約追加可能であると判定された場合には、上記仮のイベント・使用資源表を正式なイベント・使用資源表６８として採用することにより、追加予約希望のアプリケーションをイベント・使用資源表に追加することが可能になる。このような予約追加の判断にかかわる処理は、処理量が多くない。よって、この処理に必要な使用資源は少なく、システムが破綻する可能性は実質上無い。また、この処理に必要な時間も極めて短時間であるので、殆ど即座に対応することが可能である。なお、暗号アルゴリズムを使用する場合は、前処理の所要時間以上早めに予約要求が行われるべきである。そうでなければ、暗号通信の開始が遅れてしまうからである。
これまでに、暗号通信アプリケーション、前処理、リキー処理などを予約登録や追加登録する場合について説明した。スケジュール部６４がイベントを実行している最中に新たな追加の予約登録の要求が発生した場合であっても、上記各実施の形態において説明した許容資源量の余裕の範囲であればイベントの追加が可能である。スケジュール部６４は、追加予約登録要求を受けると、この予約をスケジュール・使用資源表６６に仮登録し、作成済みのイベント・使用資源表６８に追加アプリケーションに関するタスク欄を設け、さらにその開始希望時刻に対応するイベント行と終了希望時刻に対応するイベント行を挿入した、仮のイベント・使用資源表を別途作成する。そして、挿入した開始希望時刻イベント行と終了希望時刻イベント行に、各々の上段の各タスクと暗号アルゴリズムの記載内容をそれぞれコピーする。そしてさらに、開始希望時刻イベント行から終了希望時刻イベント行の直前のイベント行までの各イベント行に、追加使用希望する使用資源量を追記する。それから、スケジュール部６４と暗号情報決定部７４は、使用資源量の合計の算定や、その合計と許容資源量との比較を行ない、その合計が許容資源量未満であれば、更に必要に応じて暗号アルゴリズムの選択などの作業を行なう。最終的に予約追加可能であると判定された場合には、上記仮のイベント・使用資源表を正式なイベント・使用資源表６８として採用することにより、追加予約希望のアプリケーションをイベント・使用資源表に追加することが可能になる。このような予約追加の判断にかかわる処理は、処理量が多くない。よって、この処理に必要な使用資源は少なく、システムが破綻する可能性は実質上無い。また、この処理に必要な時間も極めて短時間であるので、殆ど即座に対応することが可能である。なお、暗号アルゴリズムを使用する場合は、前処理の所要時間以上早めに予約要求が行われるべきである。そうでなければ、暗号通信の開始が遅れてしまうからである。
反対に、登録済みのあるアプリケーションの予約を取り消す場合には、該当するイベント時刻における、そのアプリケーションを構成するタスク名と、暗号通信の場合は更に、関連する暗号アルゴリズム名と使用資源を、記載欄から削除すればよい。この処理も極めて短時間に行なえるが、スケジュール部６４がイベント・使用資源表６８を参照して作業している時間帯、すなわちイベント時刻の前後の時間帯を避けて行なうようにする方がよい。暗号アルゴリズムを使用するアプリケーションの予約を取り消す場合には、関連する前処理やリキー処理のイベントについても一緒に削除する。このとき、既に予約登録済みの他のアプリケーションの暗号アルゴリズムを予約要求元に提示することによって予約要求元による暗号アルゴリズムの変更を可能としたり、最も負荷の低いもの、あるいは最も暗号強度の低いものから暗号アルゴリズムの再選択（強度を向上させる）を行なった場合の平均使用ＣＰＵ資源合計値を算出し、この合計値が許容ＣＰＵ処理能力を超えなかった場合に暗号アルゴリズムの変更を実施したりすることも可能とする。また、アルゴリズムの再選択とは別に、アプリケーションの種類によっては、許容ＣＰＵ処理能力を超えない範囲でその実行開始時刻をずらしたり、暗号通信平均データ転送量をアプリケーションによって制御できる場合はその値を高くしたりすることによって、実行完了時刻を早めることも可能である。また、これらの変更を予約要求元が行なう場合は、認証により、変更する権限を有する者のみが変更を許可されるようにしてもよい。
図３４は、いずれかのアプリケーションの予約が取り消されたときに、その結果として生まれたＣＰＵの余力を暗号アルゴリズムの暗号強度の強化に振り向ける場合のアルゴリズム選択方法の手順を示すフローチャートである。予約取り消し指示を受けると、通信装置は、ステップＳ３４０１において、最も負荷が低い暗号アルゴリズムを使用する予定の暗号通信アプリケーションを検索する。ステップＳ３４０２において、その暗号アルゴリズムを暗号強度のより高いものに変更した場合の使用資源合計を算出し、ステップＳ３４０３において、その合計が許容ＣＰＵ処理能力未満かどうか判定する。この判定結果がＮＯなら、許容ＣＰＵ処理能力が不足であるので暗号強度の強化はできず、ステップＳ３１１２に進む。ステップＳ３４０３の判定結果がＹＥＳなら、ステップＳ３４０４において、図３１のステップＳ３１０９、ステップＳ３１１０、ステップＳ３１１１と同様に、暗号アルゴリズムの変更に対応して、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップＳ３４０５において、変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がＹＥＳならステップＳ３４０１に戻り、暗号アルゴリズムの暗号強化を試みる。ステップＳ３４０５の判定結果がＮＯなら、ステップＳ３１１２に進む。
（実施の形態の変形および補足）
使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合について補足すると、予約済み暗号通信アプリケーションおよび予約要求暗号通信アプリケーションに対して、必要なら前記一定条件（例えば暗号強度が第３位以上等）にかかわらず、暗号アルゴリズムの再選択のための計算を行ない、登録可能なら、再選択を実施して予約登録を行なうようにすることを行ってもよい。これは、予約済みの暗号通信アプリケーション用の暗号アルゴリズムが、前記一定条件を満たす暗号強度の中で強度が上位のものを採用している場合、一定条件はそのままでも、その条件下で、より暗号強度が低位のものに変更する操作を含む。また、このような変更の余地がない場合は、前記一定条件を緩和することを含む。また、前記使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合に、他のアプリケーションの実行時間の変更、暗号通信平均データ転送量を低減する変更、もしくはその他の変更を行ない、必要なら前記一定条件にかかわらず、この条件を緩めるなどにより再選択を実施して予約登録を行なうことを可能にしてもよい。上記その他の変更としては、他のアプリケーションの性能を低くしてＣＰＵ処理能力の消費量を減らすことが考えられる。このような変更が可能な場合には、このような変更を選択して、暗号アルゴリズムの処理にＣＰＵ処理能力を振り向けるようにしてもよい。
使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合について補足すると、予約済み暗号通信アプリケーションおよび予約要求暗号通信アプリケーションに対して、必要なら前記一定条件（例えば暗号強度が第３位以上等）にかかわらず、暗号アルゴリズムの再選択のための計算を行ない、登録可能なら、再選択を実施して予約登録を行なうようにすることを行ってもよい。これは、予約済みの暗号通信アプリケーション用の暗号アルゴリズムが、前記一定条件を満たす暗号強度の中で強度が上位のものを採用している場合、一定条件はそのままでも、その条件下で、より暗号強度が低位のものに変更する操作を含む。また、このような変更の余地がない場合は、前記一定条件を緩和することを含む。また、前記使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合に、他のアプリケーションの実行時間の変更、暗号通信平均データ転送量を低減する変更、もしくはその他の変更を行ない、必要なら前記一定条件にかかわらず、この条件を緩めるなどにより再選択を実施して予約登録を行なうことを可能にしてもよい。上記その他の変更としては、他のアプリケーションの性能を低くしてＣＰＵ処理能力の消費量を減らすことが考えられる。このような変更が可能な場合には、このような変更を選択して、暗号アルゴリズムの処理にＣＰＵ処理能力を振り向けるようにしてもよい。
上記説明において、許容ＣＰＵ処理能力を５０％とした。また、平均使用ＣＰＵ資源を用いた。ＣＰＵは、アプリケーションの処理以外にＯＳの処理やカーネルの処理などの基本的処理も並行して行なっているからである。また、アプリケーションの処理において、常に一定のＣＰＵ資源を使用するとは限らない。通信においてパケットが集中して到着する場合や、テレビ放送の送信においてデータレートが絵柄のよって変動する場合などもあり、これらの変動を吸収する余裕が必要である。このために、平均使用ＣＰＵ資源を用い、許容ＣＰＵ処理能力を１００％より小さい値としている。
スケジュール・使用資源表６６、イベント・使用資源表６８、暗号処理使用資源表７６の形式や、表内の各数値は、上記例に限定されない。上記例とは異なった形式であっても、必要な情報が表現でき、資源の計算ができるものであれば、本発明に使用できる。イベント時刻は、分より細かい秒、あるいは秒以下の分解能を持たせてもよい。
図１８の構成では、暗号情報決定部７４と暗号処理部８０の間で暗号・復号情報を授受するようにしたが、暗号情報決定部７４が、暗号通信アプリケーション７０、７２との間でその暗号アプリケーションに対応した暗号・復号情報を授受し、暗号通信アプリケーション７０、７２が、暗号アプリケーション自身に対応した暗号・復号情報を暗号処理部８０との間で授受するようにしてもよい。
図１８の構成において、スケジュール部６４と暗号情報決定部７４とがひとつのブロックで成り、このブロックが、スケジュール・使用資源表６６、暗号処理使用資源表７６、およびイベント・使用資源表６８の３つのテーブルを取り扱うようにしてもよい。
また、図１８の構成において、暗号情報決定部７４と暗号処理部８０がひとつのブロックで成り、このブロックが、暗号処理使用資源表７６や暗号・復号情報を扱い、スケジュール部６４、暗号通信アプリケーション７０、７２との間で、関係する情報をやり取りするようにしてもよい。
本発明の通信装置が相手の装置と暗号通信を行なう場合、両者が共に使用可能な暗号アルゴリズムを選択対象とするのが好ましい。本通信装置が選択した暗号アルゴリズムが、相手装置で対応できない場合は、暗号通信ができなくなるのは言うまでもない。したがって、上記予約の段階で、相手装置との間で、使用可能な暗号アルゴリズムを共有化するネゴシエーションを行なうことが好ましい。
通信におけるパケット送信時の揺らぎや、受信におけるパケットの順序の乱れや受信の遅れがあると、使用中の鍵から次の更新鍵に更新される時刻は、鍵の満了時刻の前後に揺らぐ可能性がある。特に受信側でその可能性が大きい。揺らぎ時間が累積してゆき、更新した鍵の使用開始時刻が、スケジュール時に予想した時刻よりも大幅にずれることが懸念される場合は、その分リキー処理開始時刻をずらしてもよい。送信側のネットワークカメラが、鍵の更新を、寿命満了時間に基づき行なう限りは、揺らぎ時間の累積は起こらない。
上記暗号アルゴリズムが認証アルゴリズムあるいは圧縮アルゴリズムであっても、本発明が適用できる。よって、上記の各暗号アルゴリズムは、認証アルゴリズムおよび圧縮アルゴリズムを含むものとする。
なお、本発明のアルゴリズム選択方法の各手順をコンピュータに実行させるためのプログラムを記録した記録媒体としては、プログラムを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ、メモリカード、ハードディスクなど、コンピュータ読み取り可能な任意の記録媒体が利用できる。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
（実施の形態１８）
以上の実施の形態１〜１７では、通信装置が自身のＣＰＵ使用率（より一般的には使用資源合計値）に基づいて最適な暗号アルゴリズムを選択する例について説明した。ところが、暗号アルゴリズムの選択にあたって通信相手（例えば、ネットワークカメラや、通信機能を有する家電機器）のＣＰＵ使用率は考慮されないため、通信相手のＣＰＵリソースに余裕があまりないときに負荷の高い暗号アルゴリズムを選択してしまうと、通信相手における暗号化パケットの復号化処理が遅延してしまう。そこで、実施の形態１８として、このような問題を回避可能な通信装置について説明する。
以上の実施の形態１〜１７では、通信装置が自身のＣＰＵ使用率（より一般的には使用資源合計値）に基づいて最適な暗号アルゴリズムを選択する例について説明した。ところが、暗号アルゴリズムの選択にあたって通信相手（例えば、ネットワークカメラや、通信機能を有する家電機器）のＣＰＵ使用率は考慮されないため、通信相手のＣＰＵリソースに余裕があまりないときに負荷の高い暗号アルゴリズムを選択してしまうと、通信相手における暗号化パケットの復号化処理が遅延してしまう。そこで、実施の形態１８として、このような問題を回避可能な通信装置について説明する。
図３５に、本実施の形態の通信装置を用いた通信システムの構成を示す。図３５に示すように、通信装置１２０は、ネットワークを介して１以上の通信相手（図３５の例では通信相手１２２、１２４、１２６）と通信可能である。
まず、本実施の形態の前提条件を以下に述べる。
＜暗号通信に関する前提条件＞
・通信装置１２０は、パケットを暗号化して、１以上の通信相手と暗号通信を行なう。
・暗号化に利用可能な暗号アルゴリズムは複数存在し、通信装置１２０と通信相手の双方がサポートしている暗号アルゴリズムであれば、任意の暗号アルゴリズムを使用することができる。
・暗号鍵は、少なくとも暗号通信の開始までに、通信装置１２０と通信相手とで共有される。
・暗号化されたパケットには、少なくともこのパケットの暗号化の際に適用された暗号アルゴリズムと暗号鍵の組を識別するための識別子が含まれる。
・暗号アルゴリズムの折衝方法や暗号鍵を共有するための仕組みについては特に不問である。
・通信装置１２０は、パケットを暗号化して、１以上の通信相手と暗号通信を行なう。
・暗号化に利用可能な暗号アルゴリズムは複数存在し、通信装置１２０と通信相手の双方がサポートしている暗号アルゴリズムであれば、任意の暗号アルゴリズムを使用することができる。
・暗号鍵は、少なくとも暗号通信の開始までに、通信装置１２０と通信相手とで共有される。
・暗号化されたパケットには、少なくともこのパケットの暗号化の際に適用された暗号アルゴリズムと暗号鍵の組を識別するための識別子が含まれる。
・暗号アルゴリズムの折衝方法や暗号鍵を共有するための仕組みについては特に不問である。
＜通信相手に関する前提条件＞
・通信相手は、パケットを本通信装置に送信するときに、実施の形態１〜１５の通信装置のように、自身のＣＰＵ使用率に応じて、ＣＰＵ使用率が許容値を超えないような暗号アルゴリズムを選択し、この暗号アルゴリズムに従ってパケットを暗号化する。
・通信相手は、暗号化されたパケットを通信装置１２０から受信したときに、このパケットに適用されている暗号アルゴリズムに従ってこのパケットを復号化する。
・通信相手は、パケットを本通信装置に送信するときに、実施の形態１〜１５の通信装置のように、自身のＣＰＵ使用率に応じて、ＣＰＵ使用率が許容値を超えないような暗号アルゴリズムを選択し、この暗号アルゴリズムに従ってパケットを暗号化する。
・通信相手は、暗号化されたパケットを通信装置１２０から受信したときに、このパケットに適用されている暗号アルゴリズムに従ってこのパケットを復号化する。
図３６は、通信装置１２０の構成を示す機能ブロック図である。図３６において、通信装置１２０は、暗号通信アプリケーション１２８、暗号情報決定部１３０、暗号処理部１３６および通信処理部１３８を備えている。暗号情報決定部１３０は、暗号処理使用資源表１３２と受信履歴管理表１３４を保持している。
図３７は、暗号処理使用資源表１３２の一例である。図３７において、「計算量」は、暗号処理を行った場合の負荷を示しており、その値としては、ある通信相手での測定結果を用いる。なお、通信相手での測定結果の替わりに、通信装置１２０での測定結果や、暗号アルゴリズムに基づいて算出される理論値を用いてもよい。また、図３７において、「計算量指標」は、計算量の順位を示しており、計算量が小さい順に１、２、３、・・・という値が設定される。また、「暗号強度」は、暗号の強さの順位を示している。
図３８は、受信履歴管理表１３４の一例である。図３８において、「Ｌａｓｔ」は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを示している。また、「度数」は、一定時間（もしくは一定個数）の受信パケットに適用されていた暗号アルゴリズムの度数を示している。図３８において、度数が「＊」であるものは、通信相手とネゴシエーションできていない暗号アルゴリズムを示している。
図３９は、通信相手１２２の構成を示す機能ブロック図である。図３９において、通信相手１２２（通信相手１２２）は、暗号通信アプリケーション１４０、リソース監視部１４２、通信処理部１４４、暗号処理部１４６および暗号情報決定部１４８を備えている。暗号情報決定部１４８は、暗号処理使用資源表１５０を保持している。なお、リソース監視部１４２、通信処理部１４４および暗号処理部１４６の機能は、図１に示したものと同様である。また、ＣＰＵ使用率情報メモリ１５０および暗号処理使用資源表１５２についても、図２に示したものと同様である。なお、通信相手１２４、１２６の構成および動作については通信相手１２２と同様のため、通信相手１２４、１２６の説明は省略する。
以下、通信装置１２０の動作を説明する。
まず、パケット受信時の通信装置１２０の動作について説明する。通信処理部１３８は、ネットワークを介して通信相手から暗号化パケットを受信し、受信した暗号化パケットを暗号処理部１３６に渡す。暗号処理部１３６は、この暗号化パケットを解析し、この暗号化パケットに適用されている暗号アルゴリズムと暗号鍵の組を識別するための識別子（以下、第１識別子とする）を抽出し、この第１識別子と、この暗号化パケットの送信元の通信相手を識別するための識別子（以下、第２識別子とする）とを暗号情報決定部１３０に渡す。暗号情報決定部１３０は、暗号処理部１３６から受け取った第１識別子に基づいて暗号アルゴリズムと暗号鍵の組を特定し、これらを暗号処理部１３６に渡す。また、暗号情報決定部１３０は、特定した暗号アルゴリズムと暗号鍵の組、および暗号処理部１３６から受け取った第２識別子に基づいて、受信履歴管理表１３４を更新する。暗号処理部１３６は、暗号情報決定部１３０から受け取った暗号アルゴリズムと暗号鍵の組を用いて暗号化パケットを復号し、こうして平文となったパケットを暗号通信アプリケーション１２８に渡す。
次に、パケット送信時の通信装置１２０の動作について説明する。暗号通信アプリケーション１２８は、通信相手に送信すべき平文のパケットを生成し、これを暗号処理部１３６に渡す。暗号処理部１３６は、暗号通信アプリケーション１２８から受け取ったパケットから第２識別子を抽出し、これを暗号情報決定部１３０に渡す。暗号情報決定部１３０は、暗号処理部１３６から受け取った第２識別子に基づいて、暗号処理使用資源表１３２および受信履歴管理表１３４を参照して暗号アルゴリズムを選択する。なお、この暗号アルゴリズム選択処理の詳細は後述する。暗号情報決定部１３０は、選択した暗号アルゴリズムを暗号処理部１３６に渡す。暗号処理部１３６は、暗号情報決定部１３０から受け取った暗号アルゴリズムにしたがってパケットを暗号化し、この暗号化パケットを通信処理部１３８に渡す。通信処理部１３８は、暗号処理部１３６から受け取ったパケットをネットワークを介して通信相手に送信する。
以下、パケット送信時における暗号情報決定部１３０の暗号アルゴリズム選択処理の詳細を説明する。前提条件として、暗号情報決定部１３０は、通信相手との間でネゴシエーションされた１以上の暗号アルゴリズム（図３８で「＊」が付いていない暗号アルゴリズム）から１つの暗号アルゴリズムを選択する。また、暗号情報決定部１３０は、通信相手毎に異なる暗号アルゴリズムを選択することができる。
なお、パケット送信時における暗号情報決定部１３０の暗号アルゴリズム選択方法には複数のバリエーションが考えられる。以下では、６つの典型的なバリエーションについて説明する。
（１）パケット送信先の通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを選択する。
通信相手は、パケット送信時のＣＰＵ使用率に応じた暗号アルゴリズムを選択し、この暗号アルゴリズムにしたがってパケットを暗号化して、この暗号化パケットを通信装置１２０に送信する。したがって、通信相手から受信したパケットに適用されていた暗号アルゴリズムは、そのパケットの送信時の通信相手のＣＰＵ使用率を反映している。よって、本方法では、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムが負荷の高いものであった場合には、現在、その通信相手のＣＰＵは余力があると予想されるため、暗号情報決定部１３０は、通信相手が送信時に適用したのと同じ、負荷の高い暗号アルゴリズムを選択してパケットを暗号化する。一方、通信相手から受信したパケットに適用されていた暗号アルゴリズムが負荷の低いものであった場合には、現在、その通信相手のＣＰＵは余力がないと予想されるため、暗号情報決定部１３０は、通信相手が送信時に適用したのと同じ、負荷の低い暗号アルゴリズムを選択してパケットを暗号化する。例えば、図３８の受信履歴管理表１３４を保持している状態で通信相手Ａにパケットを送信する場合には、暗号情報決定部１３０は、通信相手Ａの「ｌａｓｔ」の欄に基づいて、暗号アルゴリズム３ＤＥＳ−ＣＢＣを選択する。同様に、通信相手Ｃにパケットを送信する場合には、暗号情報決定部１３０は、通信相手Ｃの「ｌａｓｔ」の欄に基づいて、暗号アルゴリズムＡＥＳ−ＣＢＣを選択する。
この方法を採用する場合には、暗号情報決定部１３０は、暗号化されたパケットを受信するたびに、図３８に示す受信履歴管理表１３４の「ｌａｓｔ」の欄を更新する必要がある。なお、この方法では、受信履歴管理表１３４の「度数」の欄は不要である。
（２）パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。
通信相手のＣＰＵ使用率は常に一定というわけではないため、上記（１）の方法のように、たった一つの受信パケットに基づいて暗号アルゴリズムを選択すると、その選択結果が適切でない場合がある。よって、本方法では、暗号情報決定部１３０は、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。例えば、図３８の受信履歴管理表１３４を保持している状態で通信相手Ａにパケットを送信する場合には、暗号情報決定部１３０は、通信相手Ａの「度数」の欄を参照して、過去に受信した２０のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高い暗号アルゴリズムＤＥＳ−ＣＢＣを選択する。
この方法を採用する場合には、暗号情報決定部１３０は、暗号化されたパケットを受信するたびに、図３８に示す受信履歴管理表１３４の「度数」の欄を更新する必要がある。例えば、過去に受信した２０パケットを考慮して暗号アルゴリズムを選択する場合には、受信履歴管理表１３４の「度数」欄に２０パケット分の履歴を常に保持しておく。なお、この方法では、受信履歴管理表１３４の「ｌａｓｔ」の欄は不要である。
（３）パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。
上記（２）の方法で考慮した、過去に受信した一定数のパケットの中には、かなり前に受信したパケットが含まれる場合もあり、そのようなパケットは通信相手の現在のＣＰＵ使用率を推定するための材料としては適切ではない。よって、本方法では、暗号情報決定部１３０は、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。例えば、図３８の受信履歴管理表１３４を保持している状態で通信相手Ａにパケットを送信する場合には、暗号情報決定部１３０は、通信相手Ａの「度数」の欄を参照して、過去に受信した２０のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高い暗号アルゴリズムＤＥＳ−ＣＢＣを選択する。
この方法を採用する場合には、暗号情報決定部１３０は、暗号化されたパケットを受信するたびに、図３８に示す受信履歴管理表１３４の「度数」の欄を更新する必要がある。例えば、過去５分間に受信したパケットを考慮して暗号アルゴリズムを選択する場合には、受信履歴管理表１３４の「度数」欄に１分間分の履歴を常に保持しておく。なお、この方法では、受信履歴管理表１３４の「ｌａｓｔ」の欄は不要である。
（４）計算量が、パケット送信先の通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムの計算量以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
計算量が多い暗号アルゴリズムが必ずしも暗号強度が高いとは限らない。例えば、図３７に示すように、ＡＥＳ−ＣＢＣは、３ＤＥＳ−ＣＢＣよりも計算量は少ないが、暗号強度は高い。したがって、もし暗号アルゴリズムとしてＡＥＳ−ＣＢＣと３ＤＥＳ−ＣＢＣのどちらも利用可能な場合には、ＡＥＳ−ＣＢＣを用いる方が有効である。
また、一般に、受信用にネゴシエーションされたアルゴリズムと、送信用にネゴシエーションされたアルゴリズムは必ずしも一致せず、例えば通信相手から最後に受信したパケットに適用された暗号アルゴリズムを選択しようとしても、この暗号アルゴリズムが送信用にネゴシエーションされたものではない場合もあり得る。
よって、本方法では、暗号情報決定部１３０は、暗号処理使用資源表１３２を参照して、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムと比べて計算量が等しいかまたは少ない暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。例えば、図３８の受信履歴管理表１３４を保持している状態で通信相手Ｂにパケットを送信する場合には、暗号情報決定部１３０は、計算量が、通信相手Ｂの「ｌａｓｔ」の欄に記載されている暗号アルゴリズム３ＤＥＳ−ＣＢＣの計算量以下の暗号アルゴリズム（すなわち図３７の例では３ＤＥＳ−ＣＢＣとＡＥＳ−ＣＢＣ。なお、ＤＥＳ−ＣＢＣについては図３８に示すように通信相手Ｂとの間でネゴシエーションされていないため除外される。）の中から、最も暗号強度の高い暗号アルゴリズムＡＥＳ−ＣＢＣを選択する。
（５）計算量が、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムの計算量の統計値以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
なお、「統計値」としては、それらの暗号アルゴリズムの計算量のうちの最小値を採用してもよいし、それらの暗号アルゴリズムの計算量のうちの最も頻度の多い計算量を採用してもよいし、それらの暗号アルゴリズムの計算量の平均値を採用してもよいし、その他の統計値を採用してもよい。
例えば、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムの計算量の平均値を「統計値」として採用しており、図３８の受信履歴管理表１３４を保持している状態で通信相手Ａにパケットを送信する場合には、通信相手Ａの「度数」の欄に基づいて「統計値」は（１００×１７＋３００×３）／２０＝１３０と計算されるので、暗号情報決定部１３０は、計算量が１３０以下の暗号アルゴリズムＤＥＳ−ＣＢＣを選択する。
（６）計算量が、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
例えば、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムの計算量のうちの最も頻度の多い計算量を「統計値」として採用しており、図３８の受信履歴管理表１３４を保持している状態で通信相手Ｂにパケットを送信する場合には、通信相手Ｂの「度数」の欄に基づいて「統計値」は３ＤＥＳ−ＣＢＣの計算量である３００となるので、暗号情報決定部１３０は、計算量が３００以下の暗号アルゴリズムの中で、最も暗号強度の高い暗号アルゴリズムＡＥＳ−ＣＢＣを選択する。
なお、上記（４）〜（６）の方法において、「計算量」の替わりに図３７に示す「計算量指標」を用いて暗号アルゴリズムを選択してもよい。
なお、上記の各方法は、過去に受信したパケットに関する情報が受信履歴管理表１３４に保持されていることを前提としている。しかしながら、ある通信相手に対して初めてパケットを送信する場合や、パケット送信先から長期間パケットを受信していない場合には、受信履歴管理表１３４に十分な情報が保持されておらず、上記の各方法で暗号アルゴリズムを選択することができない。そこで、このような場合には、一例として、暗号情報決定部１３０は、予め指定した暗号アルゴリズムを選択するようにしてもよい。また、別の例として、暗号情報決定部１３０は、まずパケット送信先に、その送信先からの応答が得られるようなパケット、例えばＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）の「Ｅｃｈｏ ｒｅｑｕｅｓｔ」を送信し、これに対する応答として送信先から返ってきたパケットに適用されていた暗号アルゴリズムに基づいて、暗号アルゴリズムを選択するようにしてもよい。
図４０は、本通信システムの処理の流れを示すフローチャートである。なお、図４０において、図１６と同様のステップには同一の参照符号を付し、説明を省略する。
図４０のフローチャートから分かるように、本実施の形態における通信相手１２２の動作は、図１６に示す通信装置２４の動作とほぼ等しい。異なる点は、本実施の形態では、ステップＳ１７００の詳細を示す図１７のステップＳ１７０２で、集合Ｆの中で、ＣＰＵ使用率が許容値以下となるような暗号アルゴリズムの集合Ｄを求める点のみである。したがって、以下では、通信相手１２２の動作の説明は省略し、通信装置１２０側の動作についてのみ説明する。
暗号情報決定部１３０は、通信相手１２２から暗号化されたパケットを受信したかどうかを判定し（Ｓ１６２２）、パケットを受信した場合は、このパケットに適用されていた暗号アルゴリズムに基づいて受信履歴管理表１３４を更新する（Ｓ４００１）。
一方、通信相手１２２に送信すべきパケットが存在する場合（Ｓ１６２４でＹＥＳ）には、暗号情報決定部１３０は、上述した（１）〜（６）のような方法を用いて集合Ｆから暗号アルゴリズムをひとつ選択する（Ｓ４００２）。そして、暗号処理部１３６は、暗号情報決定部１３０によって選択された暗号アルゴリズムを用いてパケットを暗号化する（Ｓ４００３）。
なお、本実施の形態では暗号化プロトコルは不問である。例えば、ＩＰｓｅｃ（Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）やＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）等のプロトコルを用いることができる。また、暗号アルゴリズムの種別も不問である。もちろん、送信するパケットの内容も不問である。
本実施の形態では、どの暗号アルゴリズムを選択可能かを通信装置１２０と通信相手１２２との間で予め決定しておく必要がある。そのための方法の一例として、管理者が、選択可能な暗号アルゴリズムの種類を通信装置１２０と通信相手１２２の双方に予め登録しておいてもよい。また、別の例として、図４０のステップＳ１６０１およびステップＳ１６２１のように、暗号通信に先立って通信装置１２０と通信相手１２２との間でネゴシエーションのための通信を行ってもよい。このようなネゴシエーションのための通信は、例えばＩＫＥにも含まれている。
以上のように、実施の形態１８によれば、通信装置１２０は、通信相手１２２がパケット送信時に適用した暗号アルゴリズムに基づいて通信相手１２２のＣＰＵの余力を考慮し、通信相手１２２のＣＰＵの余力に応じた負荷の暗号アルゴリズムを選択することができる。よって、通信相手１２２は、通信装置１２０から送信されたパケットの復号処理を無理なくこなすことができる。また、通信装置１２０は、通信相手１２２から受信したパケットに基づいて暗号アルゴリズムを選択するため、暗号アルゴリズムを選択するための判断材料（例えば、現在のＣＰＵ使用率などの情報）を通信相手１２２から通信装置１２０に別途送信する手間（図１６のＳ１６０３のような処理）は不要である。
（実施の形態１９）
実施の形態１８における通信相手１２２のように、自分の都合に合わせて暗号アルゴリズムを選択する機能を側の装置を「主」、同じく実施の形態１８における通信装置１２０のように、相手の都合に合わせて暗号アルゴリズムを選択する側の装置を「従」とすると、通信相手１２２の機能と通信装置１２０の機能の両方を備えた通信装置は「主」と「従」の両方になり得る。以下、実施の形態１９として、そのような通信装置について説明する。
実施の形態１８における通信相手１２２のように、自分の都合に合わせて暗号アルゴリズムを選択する機能を側の装置を「主」、同じく実施の形態１８における通信装置１２０のように、相手の都合に合わせて暗号アルゴリズムを選択する側の装置を「従」とすると、通信相手１２２の機能と通信装置１２０の機能の両方を備えた通信装置は「主」と「従」の両方になり得る。以下、実施の形態１９として、そのような通信装置について説明する。
図４１は、実施の形態１９の通信装置の構成を示す機能ブロック図である。図４１において、通信装置１５４は、リソース監視部１５６、暗号通信アプリケーション１５８、暗号情報決定部１６０、暗号処理部１６８および通信処理部１７０を備える。暗号情報決定部１６０は、ＣＰＵ使用率情報メモリ１６２、暗号処理使用資源表１６４および受信履歴管理表１６６を保持している。なお、図４１の構成および動作は、暗号情報決定部１６０の動作を除いて、図３６または図３９に示したものと同様であるため、ここでは説明を省略する。暗号情報決定部１６０の動作については後述する。
ところで、２台の通信装置間で通信するときに、この２台の通信装置がいずれも「主」、あるいはいずれも「従」として機能する場合には、実施の形態１８のような望ましい効果は得られない。なぜなら、２台の通信装置がいずれも「主」として機能する場合には、一方の通信装置のＣＰＵ使用率が高い場合にも関わらず、他方の通信装置は負荷の高い暗号アルゴリズムを用いてパケットを暗号化してしまう可能性があるからである。また、２台の通信装置がいずれも「従」として機能する場合には、いずれか一方の通信装置で最初に用いられた暗号アルゴリズムを双方の通信装置が延々と使いつづけてしまう可能性があるからである。したがって、２台の通信装置間で通信するときには、いずれか一方の通信装置が「主」として機能し、他方の通信装置が「従」として機能するのが好ましい。さらには、ＣＰＵ等に比較的余力がある側の通信装置が「従」として機能するのが好ましい。なぜなら、「従」として機能する側の通信装置は、自身のＣＰＵ使用率に関わらず、常に相手に合わせた負荷の暗号アルゴリズムを用いる必要があるからである。
以下、通信装置１５４の動作を説明する。なお、以下では、図４２に示すように、実施の形態１８の通信相手１２２のように「主」としてのみ機能可能な通信装置１７２と、実施の形態１８の通信装置１２０のように「従」としてのみ機能可能な通信装置１７４と、本実施の形態の通信装置１５４のように「主」と「従」のいずれとしても機能可能な通信装置１７６とが混在する通信システムにおいて、本実施の形態の通信装置１５４を利用する場合を想定する。
各通信装置１５４、１７２、１７４、１７６の暗号情報決定部は、電源駆動時、または通信相手との最初の暗号通信開始時において、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定するためのネゴシエーション（以下、主従折衝と称す）を通信相手と行なう。ただし、このようなネゴシエーションは、通信システムの管理者が手動で行っても構わない。以下では、説明の都合上、ネゴシエーションを開始した側の通信装置を通信装置Ｘ、通信装置Ｘの通信相手を通信装置Ｙと称す。
各通信装置１５４、１７２、１７４、１７６の暗号情報決定部は、まず、各通信装置に期待されている役割にしたがって、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定しようと試みる。具体的には、まず通信装置Ｘの暗号情報決定部は、通信装置Ｘが「主」にのみなれるか、「従」にのみなれるか、「主」と「従」の両方になれるかを通信装置Ｙに通知する。通信装置Ｙの暗号情報決定部は、通信装置Ｘからの通知を受けると、通信装置Ｙが通信装置Ｘに対する適切な通信相手になることができるかどうか判定する。より具体的には、通信装置Ｘが「主」にのみなれる場合には通信装置Ｙが「従」になれるかどうか、通信装置Ｘが「従」にのみなれる場合には通信装置Ｙが「主」になれるかどうかを判定する。その結果、通信装置Ｙが通信装置Ｘに対する適切な通信相手になることができる場合には、その旨を通信装置Ｘに応答し、主従折衝は終了する。
なお、通信装置Ｘが「主」と「従」の両方になれる場合には、通信装置Ｙの暗号情報決定部は、通信装置Ｙの役割を通信装置Ｘに応答する。より具体的には、通信装置Ｙが「主」にのみなれる場合には、その旨を通信装置Ｘに応答し、通信装置Ｙが「従」にのみなれる場合には、その旨を通信装置Ｘに応答する。こうして主従折衝は終了する。
なお、通信装置Ｘが「主」と「従」の両方になれ、かつ通信装置Ｙも「主」と「従」の両方になれる場合には、以下の２通りの方法のいずれかにより、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定することができる。
第１の方法は、通信装置Ｙが、予め設定された役割を選択する方法である。具体的には、「主」か「従」のうち、予め設定された方を選択し、その旨を通信装置Ｘに通知する。通信装置Ｘは、通信装置Ｙが「主」を選択した場合には「従」となり、通信装置Ｙが「従」を選択した場合には「主」となる。こうして主従折衝は終了する。
第２の方法は、双方の処理能力を比較して、処理能力の低い方が「主」となり、処理能力の高い方が「従」となる方法である。この場合、まず、通信装置Ｙの暗号情報決定部は、通信装置Ｙの処理能力（例えば、ＣＰＵ等のハードの能力や、システムに設定された値や、その時点や過去の時点の情報に基づく暗号通信に利用可能なＣＰＵリソースなど）を通信装置Ｘに通知する。通信装置Ｘの暗号情報決定部は、この通知を受けて、通信装置Ｘの処理能力と通信装置Ｙの処理能力とを比較し、どちらが「主」となり、どちらが「従」となるかを判定する。そして、判定の結果を通信装置Ｙに通知する。こうして主従折衝は終了する。なお、通信装置Ｘが通信装置Ｙに処理能力を通知し、どちらが「主」となり、どちらが「従」となるかを通信装置Ｙが判定するようにしてもよい。この場合、通信装置Ｘから通信装置Ｙへの処理能力の通知は、前述したように、通信装置Ｘが「主」にのみなれるか、「従」にのみなれるか、「主」と「従」の両方になれるかを通信装置Ｙに通知するときに、同時に通知するようにしてもよい。
上記のようにして主従折衝が終了すると、通信装置Ｘの暗号情報決定部は、通信装置Ｘの役割（「主」か「従」か）に従って動作する。具体的には、通信装置Ｘが「主」である場合は、図４０に示した左側（すなわち通信相手１２２側）のフローチャートに従って動作し、通信装置Ｘが「従」である場合は、図４０に示した右側（すなわち通信装置１２０側）のフローチャートに従って動作する。同様に、通信装置Ｙの暗号情報決定部も、通信装置Ｙの役割に従って動作する。
以上のように、本実施の形態によれば、２台の通信装置間で通信するときに、この２台の通信装置がいずれも「主」、あるいはいずれも「従」として機能することを防止できる。
なお、上記実施の形態１〜１９の説明においては、暗号アルゴリズムの選択ついて説明したが、本発明は、認証アルゴリズムの選択にも適用できる。認証アルゴリズムとは、受信したデータが伝送途中で改ざんされていないことを確認するアルゴリズムである。さらに、本発明は、映像データ・音声データ・一般のデータなどの圧縮・伸長に関する圧縮アルゴリズムの選択にも適用できる。データ圧縮のアルゴリズムとしては、ＤＥＦＬＡＴＥやＬＺＳなど種々のものがあるが、圧縮率、処理負荷およびそのときＣＰＵ使用率を考慮して、ＣＰＵリソースが枯渇しない範囲でできるだけ圧縮率の高いアルゴリズムを選択することにより、通信回線への負荷を低減することができる。また、別の見方をすると、認証アルゴリズムにおいては、もとの認証対象データに対して複雑な計算を行って認証データを生成するという点で、また圧縮アルゴリズムにおいては、元のデータを圧縮データに変えて複雑な伸長処理を必要とする形にするという点で、いずれも暗号処理に類する点があり、上記実施の形態１〜１９を、暗号アルゴリズムの選択に変えて、認証アルゴリズムや圧縮アルゴリズムの選択に適用することが可能である。
また、暗号処理部は、一般的には、ＩＰｓｅｃ、ＳＳＬ、ＴＬＳなどの暗号通信を実現するプロトコルを１つあるいは複数備え、また、ＩＫＥなどの鍵情報取得（ＩＫＥは共有鍵交換により鍵情報を取得する。ＩＫＥはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎアルゴリズムにより鍵交換を実現する。）を行なうプロトコルによるプログラムを１つあるいは複数備えておき、ＤＥＳ−ＣＢＣ、３ＤＥＳ−ＣＢＣ、ＡＥＳなどの暗号アルゴリズムを呼び出して暗号通信を行なうものであればよい。
以下に、特許請求の範囲には明示していないが、以上の記載から読み取れる本発明のいくつかの態様について述べる。
暗号情報決定部は、暗号アルゴリズムの選択時において暗号通信アプリケーションが実行されていない場合に、非暗号通信アプリケーションによる資源使用量として、その時点までの一定期間の使用資源合計値の平均値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において暗号通信アプリケーションが実行中である場合に、非暗号通信アプリケーションによる資源使用量として、その時点までの一定期間の使用資源合計値の平均値から実行中の暗号通信アプリケーションによる資源使用量を引いた値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において実行されている複数の非暗号通信アプリケーションによる資源使用量として、これらの非暗号通信アプリケーションが過去に同じ組み合わせで実行されていた期間におけるこれらの非暗号通信アプリケーションによる資源使用量の平均値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において実行されている非暗号通信アプリケーションによる資源使用量として、非暗号通信アプリケーションに対して予め既定された値を用いるものである。
暗号情報決定部は、特定の暗号アルゴリズムを用いたときの暗号通信アプリケーションによる資源使用量として、暗号通信アプリケーションが過去に特定の暗号アルゴリズムを用いて実行されていた期間における暗号通信アプリケーションによる使用資源量の平均値を用いるものである。
暗号情報決定部は、特定の暗号アルゴリズムを用いたときの暗号通信アプリケーションによる資源使用量として、暗号通信アプリケーションと特定の暗号アルゴリズムの組み合わせに対して予め既定された値を用いるものである。
スケジュール部は、暗号処理を必要とするアプリケーションである暗号通信アプリケーションに関連するタスクの開始に先立って暗号通信用の鍵を生成する前処理をスケジュールに登録するものであり、かつ暗号アルゴリズムの使用開始予定時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値、あるいは暗号アルゴリズムの切換予定時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値に基づいて、前処理の開始時刻を決定するものである。
スケジュール部は、暗号通信用の更新鍵を生成するためのリキー処理をスケジュールに登録するものであり、かつ暗号通信用の鍵の寿命満了時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値に基づいてリキー処理の開始時刻を決定するものである。
暗号通信部は、ある暗号アルゴリズムを途中でいったん別の暗号アルゴリズムに切り替えてから再び元の暗号アルゴリズムを使用する場合に、暗号アルゴリズムを切り替える前に使用していた通信用の鍵を、別の暗号アルゴリズムの使用中も保持しておき、再び元の暗号アルゴリズムを使用するときに鍵を再利用するものである。
暗号情報決定部は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から受信した一定数のパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムのうち最も頻度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から過去一定時間以内に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムのうち最も頻度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムと比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から受信した一定数のパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値と比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から過去一定時間以内に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値と比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
通信装置は、暗号アルゴリズムに替えて、認証処理を行なうための認証アルゴリズムおよび圧縮伸長処理を行なうための圧縮アルゴリズムの少なくとも一方に適応化されたものである。
本発明は、遅延のない暗号通信が要求される用途、例えばネットワークカメラの映像を遠隔地でリアルタイムで閲覧するような用途に好適である。
１０ 放送設備
１２ ネットワークカメラ
１４ 撮影部
１６ 暗号処理部
１８ 暗号情報決定部
２０ 通信処理部
２２ インターネット
２４ 通信装置
２６ 受像部
２８ 録画アプリケーション
３０ リソース監視部
３２ 暗号情報決定部
３４ ネットワークカメラアプリケーション
３６ 通信処理部
３８ 暗号処理部
４０ ディスプレイ
４２ 暗号アルゴリズム選択部
４４ ＣＰＵ使用率情報メモリ
４６ 暗号処理使用資源表
４８ ネゴシエーションパケット作成・解釈部
５０ 暗号アルゴリズム設定部
６０ アプリケーション
６２ アプリケーション
６４ スケジュール部
６６ スケジュール・使用資源表
６８ イベント・使用資源表
７０ 暗号通信アプリケーション
７２ 暗号通信アプリケーション
７４ 暗号情報決定部
７６ 暗号処理使用資源表
７８ 通信処理部
８０ 暗号処理部
８２ リソース監視部
８４ アンテナ
８６ チューナ
８８ 音声処理
９０ 表示処理
９２ 転送手段
９４ ＣＰＵ
９６ ＲＯＭ
９８ ＲＡＭ
１００ リモコンＩＦ
１０２ リモコン
１０４ ＨＤＤ
１１６ モデム
１２０ 通信装置
１２２ 通信相手Ａ
１２４ 通信相手Ｂ
１２６ 通信相手Ｃ
１２８ 暗号通信アプリケーション
１３０ 暗号情報決定部
１３２ 暗号処理使用資源表
１３４ 受信履歴管理表
１３６ 暗号処理部
１３８ 通信処理部
１４０ 暗号通信アプリケーション
１４２ リソース監視部
１４４ 通信処理部
１４６ 暗号処理部
１４８ 暗号情報決定部
１５０ ＣＰＵ使用率情報メモリ
１５２ 暗号処理使用資源表
１５４ 通信装置
１５６ リソース監視部
１５８ 暗号通信アプリケーション
１６０ 暗号情報決定部
１６２ ＣＰＵ使用率情報メモリ
１６４ 暗号処理使用資源表
１６６ 受信履歴管理表
１６８ 暗号処理部
１７０ 通信処理部
１２ ネットワークカメラ
１４ 撮影部
１６ 暗号処理部
１８ 暗号情報決定部
２０ 通信処理部
２２ インターネット
２４ 通信装置
２６ 受像部
２８ 録画アプリケーション
３０ リソース監視部
３２ 暗号情報決定部
３４ ネットワークカメラアプリケーション
３６ 通信処理部
３８ 暗号処理部
４０ ディスプレイ
４２ 暗号アルゴリズム選択部
４４ ＣＰＵ使用率情報メモリ
４６ 暗号処理使用資源表
４８ ネゴシエーションパケット作成・解釈部
５０ 暗号アルゴリズム設定部
６０ アプリケーション
６２ アプリケーション
６４ スケジュール部
６６ スケジュール・使用資源表
６８ イベント・使用資源表
７０ 暗号通信アプリケーション
７２ 暗号通信アプリケーション
７４ 暗号情報決定部
７６ 暗号処理使用資源表
７８ 通信処理部
８０ 暗号処理部
８２ リソース監視部
８４ アンテナ
８６ チューナ
８８ 音声処理
９０ 表示処理
９２ 転送手段
９４ ＣＰＵ
９６ ＲＯＭ
９８ ＲＡＭ
１００ リモコンＩＦ
１０２ リモコン
１０４ ＨＤＤ
１１６ モデム
１２０ 通信装置
１２２ 通信相手Ａ
１２４ 通信相手Ｂ
１２６ 通信相手Ｃ
１２８ 暗号通信アプリケーション
１３０ 暗号情報決定部
１３２ 暗号処理使用資源表
１３４ 受信履歴管理表
１３６ 暗号処理部
１３８ 通信処理部
１４０ 暗号通信アプリケーション
１４２ リソース監視部
１４４ 通信処理部
１４６ 暗号処理部
１４８ 暗号情報決定部
１５０ ＣＰＵ使用率情報メモリ
１５２ 暗号処理使用資源表
１５４ 通信装置
１５６ リソース監視部
１５８ 暗号通信アプリケーション
１６０ 暗号情報決定部
１６２ ＣＰＵ使用率情報メモリ
１６４ 暗号処理使用資源表
１６６ 受信履歴管理表
１６８ 暗号処理部
１７０ 通信処理部
Claims (35)
- 予め用意された複数の暗号アルゴリズムの中から、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択する暗号情報決定部と、
前記暗号情報決定部が選択した暗号アルゴリズムにしたがってパケットを暗号化する暗号処理部と、
前記暗号処理部が暗号化したパケットを送信する通信処理部とを備えた通信装置。 - 前記使用資源合計値が、当該通信装置のＣＰＵが実行すべき各アプリケーションのＣＰＵ使用率の合計値であり、
前記暗号処理部が、ＣＰＵにより暗号処理を行なうものであることを特徴とする、請求項１に記載の通信装置。 - 当該通信装置は、現在の資源使用量を監視するリソース監視部をさらに備え、
前記暗号情報決定部は、前記リソース監視部から通知される資源使用量に基づいて前記使用資源合計値を算出するものであることを特徴とする、請求項１に記載の通信装置。 - 前記暗号情報決定部は、前記リソース監視部から通知される資源使用量を記憶するための資源使用量情報メモリを有しており、当該資源使用量情報メモリに記憶されている一定期間の資源使用量の平均値に基づいて前記使用資源合計値を算出するものであることを特徴とする、請求項３に記載の通信装置。
- 前記暗号アルゴリズムに替えて、認証処理を行なうための認証アルゴリズムおよび圧縮伸長処理を行なうための圧縮アルゴリズムの少なくとも一方に適応化された、請求項１に記載の通信装置。
- 前記暗号情報決定部は、予め用意された前記複数の暗号アルゴリズムのうち、その暗号アルゴリズムを使用したときの予測される使用資源合計値が第１基準値を超えないような暗号アルゴリズムを選択するものであることを特徴とする、請求項１に記載の通信装置。
- 前記暗号情報決定部は、暗号処理の負荷を暗号アルゴリズム毎に記憶する暗号処理使用資源表を有しており、当該暗号処理使用資源表に基づいて、その暗号アルゴリズムを使用したときの使用資源合計値を算出するものであることを特徴とする、請求項６に記載の通信装置。
- 前記暗号情報決定部は、その暗号アルゴリズムを使用したときの使用資源合計値が所定の許容値を超えないような暗号アルゴリズムの中で、暗号強度が最も高いものを選択するものであることを特徴とする、請求項６に記載の通信装置。
- 前記使用資源合計値が、暗号処理を必要とするアプリケーションである暗号通信アプリケーションによる資源使用量と、暗号処理を必要としないアプリケーションである非暗号通信アプリケーションによる資源使用量の合計値であることを特徴とする、請求項６に記載の通信装置。
- 前記暗号情報決定部は、暗号処理実行中の任意の時点までの一定期間における前記使用資源合計値の平均値が第２基準値よりも高い場合に、その時点で使用している暗号アルゴリズムよりも負荷の低い暗号アルゴリズムを選択するものであることを特徴とする、請求項１に記載の通信装置。
- 前記暗号情報決定部は、暗号処理実行中の任意の時点までの一定期間における前記使用資源合計値の平均値が第３基準値よりも低い場合に、その時点で使用している暗号アルゴリズムよりも暗号強度の高い暗号アルゴリズムを選択するものであることを特徴とする、請求項１に記載の通信装置。
- 前記暗号情報決定部は、過去のある時点における実際の使用資源合計値と、現時点における実際の使用資源合計値の差が一定値以上あった場合に、暗号アルゴリズムの再選択を行なうものであることを特徴とする、請求項１に記載の通信装置。
- 前記暗号情報決定部は、当該通信装置の通信相手との間で、複数の暗号アルゴリズムを利用することを予めネゴシエーションしておき、前記暗号処理部がパケットを暗号化するときに、当該予めネゴシエーションしておいた複数の暗号アルゴリズムの中から、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択するものであることを特徴とする、請求項１に記載の通信装置。
- 当該通信装置は、アプリケーションの実行の予約を受け付けて当該アプリケーションの実行をスケジュールに登録するスケジュール部をさらに備え、
前記暗号情報決定部は、前記スケジュールに基づいて予測される未来の時点での使用資源合計値に基づいて、その時点で使用すべき暗号アルゴリズムを選択するものであることを特徴とする、請求項１に記載の通信装置。 - 前記スケジュールは、予約されたアプリケーションに関連するタスク毎に、その開始時刻、終了時刻および使用資源量を登録するためのスケジュール・使用資源表を含み、
前記スケジュール部は、アプリケーションの実行の予約を受け付けて当該アプリケーションに関連するタスクの実行を前記スケジュール・使用資源表に登録するものであり、
前記暗号情報決定部は、暗号処理を必要とするアプリケーションである暗号通信アプリケーションに関連するタスク毎に、当該タスクが実行される期間において、その暗号アルゴリズムを使用したときの予想される前記使用資源合計値が第１基準値を超えないような暗号アルゴリズムを選択するものであることを特徴とする、請求項１４に記載の通信装置。 - 前記スケジュールは、予約されたアプリケーションに関連するタスク毎に、その開始時刻、終了時刻および使用資源量を登録するためのスケジュール・使用資源表と、各前記タスクの開始時刻および終了時刻によって区分されるイベント区間毎に、そのイベント区間における前記使用資源合計値を登録するためのイベント・使用資源表とを含み、
前記スケジュール部は、アプリケーションの実行の予約を受け付けて当該アプリケーションに関連するタスクの実行を前記スケジュール・使用資源表に登録し、当該スケジュール・使用資源表に基づいて前記イベント・使用資源表を作成するものであり、
前記暗号情報決定部は、暗号処理を必要とするアプリケーションである暗号通信アプリケーションに関連するタスクで使用される暗号アルゴリズムとして、前記イベント区間毎に、当該イベント区間において前記使用資源合計値が第１基準値を超えないような暗号アルゴリズムを選択するものであることを特徴とする、請求項１４に記載の通信装置。 - 前記スケジュール部は、暗号処理を必要とするアプリケーションである暗号通信アプリケーションに関連するタスクの開始に先立って暗号通信用の鍵を生成する前処理を前記スケジュールに登録するものであり、かつ前記暗号通信アプリケーションに関連するあるタスクの開始予定時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値に基づいて前記前処理の開始時刻を決定するものであることを特徴とする、請求項１４に記載の通信装置。
- 前記スケジュール部は、前記使用資源合計値が許容資源使用量を越えてしまうために新規の予約を前記スケジュールに登録できない場合に、すでに前記スケジュールにその使用が登録されている暗号アルゴリズムを可能であればより負荷の小さいものに変更するような暗号アルゴリズムの再選択を実行するものであることを特徴とする、請求項１４に記載の通信装置。
- 前記スケジュール部は、前記使用資源合計値が許容資源使用量を越えてしまうために新規の予約を前記スケジュールに登録できない場合に、すでに前記スケジュールに登録されているアプリケーションの、実行時間の変更または暗号通信平均データ転送量を低減する変更を行なうものであることを特徴とする、請求項１４に記載の通信装置。
- 前記スケジュール部は、前記スケジュールに登録されていたいずれかのアプリケーションの予約が取り消されたときに、すでに前記スケジュールにその使用が登録されている暗号アルゴリズムを可能であればより暗号強度の高いものに変更するような暗号アルゴリズムの再選択を実行するものであることを特徴とする、請求項１４に記載の通信装置。
- 予め用意された複数の暗号アルゴリズムの中から、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択する暗号情報決定ステップと、
前記暗号情報決定ステップで選択した暗号アルゴリズムにしたがってパケットを暗号化する暗号処理ステップと、
前記暗号処理ステップで暗号化したパケットを送信する通信処理ステップとを備えたアルゴリズム選択方法。 - 請求項２１に記載の各ステップをコンピュータに実行させるためのアルゴリズム選択プログラム。
- 請求項２２に記載のアルゴリズム選択プログラムを記録したコンピュータ読み取り可能な記録媒体。
- 予め用意された複数の暗号アルゴリズムの中から、通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択する暗号情報決定部と、
前記暗号情報決定部が選択した暗号アルゴリズムにしたがって前記通信相手宛てのパケットを暗号化する暗号処理部と、
前記暗号処理部が暗号化したパケットを送信する通信処理部とを備えた通信装置。 - 前記暗号情報決定部は、前記通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムを記憶するための受信履歴管理表を有しており、当該受信履歴管理表を参照して、前記受信したパケットに適用されていた暗号アルゴリズムのうち最も頻度の高い暗号アルゴリズムを選択するものであることを特徴とする、請求項２４に記載の通信装置。
- 前記暗号情報決定部は、前記通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムを記憶するための受信履歴管理表と、前記予め用意された各暗号アルゴリズムの暗号強度および計算量に関する情報を記憶するための暗号処理使用資源表とを有しており、当該受信履歴管理表および当該暗号処理使用資源表を参照して、前記受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値と比べて計算量が等しいかまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものであることを特徴とする、請求項２４に記載の通信装置。
- 前記暗号情報決定部は、暗号アルゴリズムを選択するための判断材料となるパケットを前記通信相手から受信していない場合に、当該通信相手からの応答を伴うパケットを前記通信処理部に送信させるものであることを特徴とする、請求項２４に記載の通信装置。
- 予め用意された複数の暗号アルゴリズムの中から、通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択する暗号情報決定ステップと、
前記暗号情報決定ステップで選択した暗号アルゴリズムにしたがって前記通信相手宛てのパケットを暗号化する暗号処理ステップと、
前記暗号処理ステップで暗号化したパケットを送信する通信処理ステップとを備えたアルゴリズム選択方法。 - 請求項２８に記載の各ステップをコンピュータに実行させるためのアルゴリズム選択プログラム。
- 請求項２９に記載のアルゴリズム選択プログラムを記録したコンピュータ読み取り可能な記録媒体。
- 請求項１に記載の通信装置である第１の通信装置と、当該第１の通信装置と通信可能に接続される請求項２４に記載の通信装置である第２の通信装置とを備えた通信システム。
- 予め用意された複数の暗号アルゴリズムの中から、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択する機能と、通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択する機能の両方を有する暗号情報決定部と、
前記暗号情報決定部が選択した暗号アルゴリズムにしたがって前記通信相手宛のパケットを暗号化する暗号処理部と、
前記暗号処理部が暗号化したパケットを送信する通信処理部とを備えた通信装置。 - 前記暗号情報決定部は、前記通信相手との主従関係を確認するために当該通信相手と通信による主従折衝処理を行なうものであり、当該主従関係に基づいて、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択するか、通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択するかを切り替えて動作するものであることを特徴とする、請求項３２に記載の通信装置。
- 前記暗号情報決定部は、前記主従折衝処理において当該通信装置の処理能力と前記通信相手の処理能力の比較を行なうものであり、当該通信装置の処理能力が当該通信相手の処理能力を下回る場合は、予測される使用資源合計値または実際の使用資源合計値に応じて異なる暗号アルゴリズムを選択し、当該通信装置の処理能力が当該通信相手の処理能力を上回る場合は、当該通信相手から受信した１以上のパケットに適用されていた暗号アルゴリズムに応じて異なる暗号アルゴリズムを選択するものであることを特徴とする、請求項３３に記載の通信装置。
- 前記暗号アルゴリズムに替えて、認証処理を行なうための認証アルゴリズムおよび圧縮伸長処理を行なうための圧縮アルゴリズムの少なくとも一方に適応化された、請求項３２に記載の通信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003367891A JP4566546B2 (ja) | 2002-10-31 | 2003-10-28 | 通信装置、通信システムおよびアルゴリズム選択方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002318189 | 2002-10-31 | ||
| JP2003023797 | 2003-01-31 | ||
| JP2003367891A JP4566546B2 (ja) | 2002-10-31 | 2003-10-28 | 通信装置、通信システムおよびアルゴリズム選択方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004254286A true JP2004254286A (ja) | 2004-09-09 |
| JP2004254286A5 JP2004254286A5 (ja) | 2006-10-05 |
| JP4566546B2 JP4566546B2 (ja) | 2010-10-20 |
Family
ID=33033044
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003367891A Expired - Fee Related JP4566546B2 (ja) | 2002-10-31 | 2003-10-28 | 通信装置、通信システムおよびアルゴリズム選択方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4566546B2 (ja) |
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006094913A (ja) * | 2004-09-28 | 2006-04-13 | Toshiba Corp | 医用動画像記録システム及び医用動画像記録方法並びに医用動画像記録プログラム |
| JP2006186470A (ja) * | 2004-12-27 | 2006-07-13 | Toshiba Corp | 無線通信機器、プログラム、及び無線通信方法 |
| JP2007004493A (ja) * | 2005-06-23 | 2007-01-11 | Sharp Corp | サーバ機能とクライアント機能とを備える情報処理装置、およびそれに用いるプログラムおよび記録媒体 |
| WO2008029823A1 (en) * | 2006-09-05 | 2008-03-13 | Sony Corporation | Communication system and communication method |
| JP2008141290A (ja) * | 2006-11-30 | 2008-06-19 | Sharp Corp | Ｎｉｃを備えるシステム機器および同システム機器の省電力制御方法 |
| JP2009055315A (ja) * | 2007-08-27 | 2009-03-12 | Nec Personal Products Co Ltd | トランスコーダ、トランスコーディング方法及びトランスコーディング用プログラム |
| JP2009087035A (ja) * | 2007-09-28 | 2009-04-23 | Toshiba Solutions Corp | 暗号クライアント装置、暗号パッケージ配信システム、暗号コンテナ配信システム、暗号管理サーバ装置、ソフトウェアモジュール管理装置、ソフトウェアモジュール管理プログラム |
| JP2009253563A (ja) * | 2008-04-03 | 2009-10-29 | Nec Corp | コンテンツ暗号化配信システム、コンテンツ暗号化配信方法およびコンテンツ暗号化配信用プログラム |
| US7835394B2 (en) | 2004-10-26 | 2010-11-16 | Nec Corporation | Dynamic setting of transmission scheduler algorithms |
| JP2012507963A (ja) * | 2008-11-04 | 2012-03-29 | マイクロソフト コーポレーション | アクセス・ポイントにおける多数の事前共有キーのサポート |
| JP2014006619A (ja) * | 2012-06-22 | 2014-01-16 | Fujitsu Ltd | 携帯端末装置の制御方法、制御プログラム及び携帯端末装置 |
| JP2014017595A (ja) * | 2012-07-06 | 2014-01-30 | Toshiba Corp | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| JP2014072662A (ja) * | 2012-09-28 | 2014-04-21 | Toshiba Corp | 通信制御方法 |
| JP2014150410A (ja) * | 2013-02-01 | 2014-08-21 | Konica Minolta Inc | 画像形成装置及び暗号強度の切り替え方法 |
| JP2014197726A (ja) * | 2013-03-29 | 2014-10-16 | 株式会社東芝 | 計測装置、情報処理装置、鍵管理装置および使用量計算システム |
| WO2014184938A1 (ja) * | 2013-05-16 | 2014-11-20 | 富士通株式会社 | 端末装置、通信システム及び通信制御プログラム |
| JP2015097423A (ja) * | 2015-01-21 | 2015-05-21 | 株式会社東芝 | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| JP2017038413A (ja) * | 2016-11-24 | 2017-02-16 | 株式会社東芝 | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| WO2017104060A1 (ja) * | 2015-12-17 | 2017-06-22 | 株式会社アイ・エル・シー | 暗号化方法および暗号化装置 |
| JP2020149605A (ja) * | 2019-03-15 | 2020-09-17 | 日本電気株式会社 | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理システム |
| CN114221825A (zh) * | 2022-02-23 | 2022-03-22 | 武汉海牛泰克信息技术有限公司 | 一种基于数字信息传输的加密系统 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11296319A (ja) * | 1998-04-06 | 1999-10-29 | Canon Inc | 印刷制御装置および印刷制御方法およびコンピュータが読み出し可能なプログラムを格納した記憶媒体 |
| JP2001202266A (ja) * | 2000-01-21 | 2001-07-27 | Denso Corp | 車載制御ユニットの検査方法 |
-
2003
- 2003-10-28 JP JP2003367891A patent/JP4566546B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11296319A (ja) * | 1998-04-06 | 1999-10-29 | Canon Inc | 印刷制御装置および印刷制御方法およびコンピュータが読み出し可能なプログラムを格納した記憶媒体 |
| JP2001202266A (ja) * | 2000-01-21 | 2001-07-27 | Denso Corp | 車載制御ユニットの検査方法 |
Cited By (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006094913A (ja) * | 2004-09-28 | 2006-04-13 | Toshiba Corp | 医用動画像記録システム及び医用動画像記録方法並びに医用動画像記録プログラム |
| JP4612381B2 (ja) * | 2004-09-28 | 2011-01-12 | 株式会社東芝 | 医用動画像記録システム及び医用動画像記録方法並びに医用動画像記録プログラム |
| US7835394B2 (en) | 2004-10-26 | 2010-11-16 | Nec Corporation | Dynamic setting of transmission scheduler algorithms |
| JP2006186470A (ja) * | 2004-12-27 | 2006-07-13 | Toshiba Corp | 無線通信機器、プログラム、及び無線通信方法 |
| JP2007004493A (ja) * | 2005-06-23 | 2007-01-11 | Sharp Corp | サーバ機能とクライアント機能とを備える情報処理装置、およびそれに用いるプログラムおよび記録媒体 |
| JP4627222B2 (ja) * | 2005-06-23 | 2011-02-09 | シャープ株式会社 | サーバ機能とクライアント機能とを備える情報処理装置、およびそれに用いるプログラムおよび記録媒体 |
| JP2008066834A (ja) * | 2006-09-05 | 2008-03-21 | Sony Corp | 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体 |
| US8811613B2 (en) | 2006-09-05 | 2014-08-19 | Sony Corporation | Communication system and communication method |
| WO2008029823A1 (en) * | 2006-09-05 | 2008-03-13 | Sony Corporation | Communication system and communication method |
| US9973479B2 (en) | 2006-09-05 | 2018-05-15 | Sony Corporation | Communication system and communication method for communication based on encryption capabilities of device |
| US9325673B2 (en) | 2006-09-05 | 2016-04-26 | Sony Corporation | Communication system and communication method |
| KR101464768B1 (ko) * | 2006-09-05 | 2014-11-24 | 소니 주식회사 | 정보 처리 장치, 정보 처리 방법, 디바이스 및 기록 매체 |
| JP2008141290A (ja) * | 2006-11-30 | 2008-06-19 | Sharp Corp | Ｎｉｃを備えるシステム機器および同システム機器の省電力制御方法 |
| JP2009055315A (ja) * | 2007-08-27 | 2009-03-12 | Nec Personal Products Co Ltd | トランスコーダ、トランスコーディング方法及びトランスコーディング用プログラム |
| JP2009087035A (ja) * | 2007-09-28 | 2009-04-23 | Toshiba Solutions Corp | 暗号クライアント装置、暗号パッケージ配信システム、暗号コンテナ配信システム、暗号管理サーバ装置、ソフトウェアモジュール管理装置、ソフトウェアモジュール管理プログラム |
| US8417964B2 (en) | 2007-09-28 | 2013-04-09 | Toshiba Solutions Corporation | Software module management device and program |
| JP2009253563A (ja) * | 2008-04-03 | 2009-10-29 | Nec Corp | コンテンツ暗号化配信システム、コンテンツ暗号化配信方法およびコンテンツ暗号化配信用プログラム |
| JP2012507963A (ja) * | 2008-11-04 | 2012-03-29 | マイクロソフト コーポレーション | アクセス・ポイントにおける多数の事前共有キーのサポート |
| JP2014006619A (ja) * | 2012-06-22 | 2014-01-16 | Fujitsu Ltd | 携帯端末装置の制御方法、制御プログラム及び携帯端末装置 |
| JP2014017595A (ja) * | 2012-07-06 | 2014-01-30 | Toshiba Corp | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| US9306734B2 (en) | 2012-07-06 | 2016-04-05 | Kabushiki Kaisha Toshiba | Communication device, key generating device, and computer readable medium |
| JP2014072662A (ja) * | 2012-09-28 | 2014-04-21 | Toshiba Corp | 通信制御方法 |
| JP2014150410A (ja) * | 2013-02-01 | 2014-08-21 | Konica Minolta Inc | 画像形成装置及び暗号強度の切り替え方法 |
| JP2014197726A (ja) * | 2013-03-29 | 2014-10-16 | 株式会社東芝 | 計測装置、情報処理装置、鍵管理装置および使用量計算システム |
| JP5994936B2 (ja) * | 2013-05-16 | 2016-09-21 | 富士通株式会社 | 端末装置、通信システム及び通信制御プログラム |
| WO2014184938A1 (ja) * | 2013-05-16 | 2014-11-20 | 富士通株式会社 | 端末装置、通信システム及び通信制御プログラム |
| JP2015097423A (ja) * | 2015-01-21 | 2015-05-21 | 株式会社東芝 | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| WO2017104060A1 (ja) * | 2015-12-17 | 2017-06-22 | 株式会社アイ・エル・シー | 暗号化方法および暗号化装置 |
| JPWO2017104060A1 (ja) * | 2015-12-17 | 2018-07-26 | 株式会社アイ・エル・シー | 暗号化方法および暗号化装置 |
| JP2017038413A (ja) * | 2016-11-24 | 2017-02-16 | 株式会社東芝 | 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム |
| JP2020149605A (ja) * | 2019-03-15 | 2020-09-17 | 日本電気株式会社 | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理システム |
| JP7218630B2 (ja) | 2019-03-15 | 2023-02-07 | 日本電気株式会社 | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理システム |
| CN114221825A (zh) * | 2022-02-23 | 2022-03-22 | 武汉海牛泰克信息技术有限公司 | 一种基于数字信息传输的加密系统 |
| CN114221825B (zh) * | 2022-02-23 | 2022-05-24 | 武汉海牛泰克信息技术有限公司 | 一种基于数字信息传输的加密系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4566546B2 (ja) | 2010-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100949420B1 (ko) | 통신장치, 통신 시스템 및 알고리즘 선택방법 | |
| JP4566546B2 (ja) | 通信装置、通信システムおよびアルゴリズム選択方法 | |
| JP4698106B2 (ja) | 送信された情報をコピー保護するシステム及び方法 | |
| KR101320350B1 (ko) | 보안관제서버 및 보안관제서버의 영상데이터 관리 방법 | |
| RU2329613C2 (ru) | Способ безопасной передачи данных по схеме "точка-точка" и электронный модуль, реализующий этот способ | |
| EP1253762A1 (en) | Process for managing a symmetric key in a communication network and devices for the implementation of this process | |
| US7062658B1 (en) | Secure digital appliance and method for protecting digital content | |
| JP4870675B2 (ja) | コンテンツ管理システム及びコンテンツ管理装置 | |
| KR20140134692A (ko) | 무선 디스플레이 스크린으로 콘텐츠를 제공하기 위한 시스템 및 방법 | |
| KR20150069982A (ko) | 보안 통신방법 및 장치와 이를 채용하는 멀티미디어 기기 | |
| WO2002086685A2 (en) | License management system, license management device, relay device and terminal device | |
| BRPI0715101A2 (pt) | dispositivo terminal, dispositivo servidor, e sistema de distribuiÇço de conteédo | |
| EP3691257B1 (en) | Internet protocol camera security system allowing secure encryption information to be transmitted | |
| WO2014152060A1 (en) | Protection of control words employed by conditional access systems | |
| US20080037788A1 (en) | Data decryption apparatus and data encryption apparatus | |
| US20140270161A1 (en) | Method and apparatus for secure storage and retrieval of live off disk media programs | |
| CN112165596A (zh) | 监控视频数据传输方法、装置、终端设备和存储介质 | |
| US7916867B2 (en) | Content receiving apparatus | |
| US20180013830A1 (en) | Method and system for managing encrypted data of devices | |
| JP2005518769A (ja) | 第２ドメインに属するネットワークにおいて第１ドメイン用に暗号化されたデータの処理装置及び伝送方法 | |
| JP2005318281A (ja) | 通信システムおよび通信装置 | |
| JP2006094342A (ja) | サーバー型コンテンツ提供システム、サーバー型コンテンツ提供装置、コンテンツ利用装置、サーバー型コンテンツ提供方法及びコンテンツ利用方法 | |
| JP2008054308A (ja) | 端末装置、サーバ装置及びコンテンツ配信システム | |
| JP2004363995A (ja) | 画像伝送システム、撮影装置 | |
| JP2010263532A (ja) | コンテンツ記録再生システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060822 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060822 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100119 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100317 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100714 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100804 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130813 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |