以下、本発明の種々の実施の形態を、図面を参照して説明する。
(実施の形態1)
図1は、本発明の実施の形態1に関わるシステムの構成図である。図1において、実施の形態1のシステムは、放送設備10と、通信装置24と、ネットワークカメラ12と、インターネット22と、ディスプレイ(映像表示装置)40とから構成される。
次に、ネットワークカメラ12および通信装置24の持つ機能を詳細に述べる。ネットワークカメラ12は、撮影部14と、暗号処理部16と、暗号情報決定部18と、通信処理部20とを具備する。なお、撮影部14と暗号処理部16の間に、図43に示したような暗号通信アプリケーション200を具備していてもよい。
また、通信装置24は、通信機能と録画機能を有する家電機器であって、受像部26と、録画アプリケーション28と、リソース監視部30と、暗号情報決定部32と、通信処理部36と、暗号処理部38と、ネットワークカメラアプリケーション34とを具備する。なお、図1において破線で囲んだ構成部分、すなわち録画アプリケーション28、リソース監視部30、暗号情報決定部32、通信処理部36、暗号処理部38、ネットワークカメラアプリケーション34は、内蔵CPUがソフトウェアを実行することにより実現される。なお、本発明のアルゴリズム選択方法は、本実施の形態においては通信装置24内の暗号情報決定部32において用いられるものとして説明する。
次に、本システムの動作について説明する。
まず、TV録画を行なう際のシステムの動作について説明する。受像部26は放送設備10が放送しているTV放送データを受信する。続いて、受信されたTV放送データを、録画アプリケーション28が、通信装置24内蔵の蓄積媒体に記録する。この処理は内蔵のCPUを利用して行われる。以上の処理を、録画したいTV番組の放送開始時刻から放送終了時刻まで連続的に行なうことで、TV録画が完了する。
次に、ネットワークカメラ12の映像をディスプレイ40に表示する際のシステムの動作について説明する。この処理は、暗号通信を行なうための事前処理と、実際にネットワークカメラアプリケーション34を動作させる処理の2つに分かれる。暗号通信を行なうための事前処理については後述し、はじめに、実際にネットワークカメラアプリケーション34を動作させる処理の概要について述べる。まず、ネットワークカメラ12では、撮影部14が撮影した映像データを、暗号処理部16が暗号化する。通信処理部20は、その暗号化された映像データを通信装置24宛のパケットとしてインターネット22に送出する。通信装置24では、通信処理部36でインターネット22から暗号化パケットを受信し、暗号処理部38で復号化し、ネットワークカメラアプリケーション34は、復号化された映像データをディスプレイ40に出力する。そして、ディスプレイ40が映像を表示する。以上のようにして、ネットワークカメラ12で撮影された映像がディスプレイ40に表示される。
次に、暗号通信を行なうための事前処理について説明する。ここでいう事前処理とは、ネットワークカメラ12内の暗号情報決定部18と、通信装置24内の暗号情報決定部32との間で、暗号通信に利用する暗号アルゴリズムおよび暗号化鍵、復号化鍵としてどのようなものを使用するかを折衝し、それぞれの暗号処理部16、38に設定する処理である。以下、通信装置24の内蔵CPUによって行われるべき処理の負荷が図44に示したように内蔵CPUの処理能力を超えてしまう事態を防止するための折衝について説明する。
図2は、通信装置24の、ネゴシエーションに関わる構成部分を示すブロック図である。データ送信側とデータ受信側が同じ暗号アルゴリズムを使用するために、双方の間でネゴシエーションが行われる。通信処理部36は、相手の通信処理部との間でデータパケットの通信を行なう。暗号アルゴリズムのネゴシエーションにおいては、ネゴシエーション用のパケットを相手との間でやり取りする。ネゴシエーションパケット作成・解釈部48は、送信時には、暗号アルゴリズム選択部42の指示に基づき、送信用のネゴシエーションパケットを所定の形式で作成し、受信時には、受信したネゴシエーションパケットの内容を解釈して暗号アルゴリズム選択部42に入手情報を渡す。暗号アルゴリズム選択部42は、決定した暗号アルゴリズムを暗号アルゴリズム設定部50に知らせて、アルゴリズム設定を指示する。暗号処理部38は、設定された暗号アルゴリズムを使用してデータの暗号化や復号化を行なう。暗号アルゴリズム選択部42は、リソース監視部30からあらかじめあるいはネゴシエーション時に入手したCPU使用率情報を格納するためのCPU使用率情報メモリ44を有している。本実施の形態では、暗号アルゴリズム選択部42は、暗号処理使用資源表46や、リソース監視部30から得たCPU使用率情報を参照しながら、暗号アルゴリズムの提案処理や選択処理を行なう。暗号処理使用資源表46については、後述する。
なお、本実施の形態では、暗号情報決定部32がネゴシエーションパケットを生成してこれを暗号化した後、通信処理部36を通じてこの暗号化されたネゴシエーションパケットを送信するが、他の形態でも構わない。例えば、暗号情報決定部32がネゴシエーションパケットを生成し、暗号処理部38がそのネゴシエーションパケットを暗号化した後、この暗号化されたネゴシエーションパケットが通信処理部36を通じて送信されてもよい。また、例えば、暗号情報決定部32がネゴシエーションパケットを生成し、暗号処理部38がそのネゴシエーションパケットを暗号化した後、この暗号化されたネゴシエーションパケットをいったん暗号情報決定部32に返し、暗号情報決定部32が通信処理部36を通じてこの暗号化されたネゴシエーションパケットを送信してもよい。
ここで、CPU使用率について説明する。CPU使用率は、CPUの最大処理能力を100%とした場合、録画アプリケーション28やネットワークカメラアプリケーション34などの個々のアプリケーションが使用するCPU処理能力を%で表したものである。CPUの処理方式には種々の方式が存在するが、最も一般的なものは、ある時刻にタスクを一つだけ処理する方式である。複数のタスクを処理する場合は、それらのタスクを時分割で処理することにより、同時並行して処理しているように見せている。軽いタスクには短い時間を、重いタスクには長い時間を割り当てる方法がある。また、時間を一定の短い処理時間単位(タイムスロット、スレッドなどと呼ぶ。)で区切り、重いタスクには軽いタスクよりも頻繁に単位時間を割り当てるようにする方法もある。CPUリソースに余裕があり、CPUがモニタプログラムなどの共通的処理以外のタスクを処理していない時間や処理時間単位は、アイドル状態として検出される。このようなCPU方式において、タスクのCPU使用率を計測するには以下のようにすればよい。CPUのOS内のモニタプログラムなどを使用して、比較的短時間毎に、処理しているタスクが何であるかをサンプリングして調べさせる。アプリケーションAがタスクAにより構成されている場合を考える。1000回調べた結果、500回がタスクAで、残りの500回はCPUが待機状態、すなわちアイドル状態であったとする。この場合は、アプリケーションAのCPU使用率は50%である。CPUは、OSのモニタプログラムなどの共通的カーネル処理を行なうが、この処理は全体から見ると少ないので、一応ここでは無視することとする。
サンプル数はある程度多くして、その時刻の瞬間CPU使用率ではなく、ある程度平滑化されたCPU使用率、例えばその時刻までの一定時間の平均CPU使用率を計測して用いるのが好ましい。瞬間あるいは短時間のCPU使用率は一時的に大きく変動するので、アプリケーションが必要とするCPU処理能力を算出するのには適さない。
アプリケーションAの処理が2つの部分に別れていて、タスクAとカーネル処理とにより実行される場合に、タスクAが500回、カーネル処理が100回、アイドル状態が400回と計測された場合は、アプリケーションAのCPU使用率は60%となる。また、タスクAは50%、カーネル部分は10%と計測できる。つぎに、アプリケーションAとアプリケーションBの2つの処理プログラムが並行して実行される場合について説明する。アプリケーションBもその一部がカーネルにおいて処理されるものとする。カーネルにおいてはアプリケーションAとアプリケーションBの各一部が処理されるが、カーネル全体のCPU使用率しか計測できないことが多い。すなわち、カーネルの中でどのようなアプリケーションが処理されているのか、また共通カーネル処理が実行されているのか、などは区別できないことが多い。従って、このケースでは、アプリケーションAとアプリケーションBのCPU使用率の合計値は、100%からアイドル処理のCPU使用率を差し引いたものとして計測できるものの、アプリケーションAとアプリケーションBの個々のCPU使用率は計測できない。なぜなら、カーネル処理の内のアプリケーションAとアプリケーションBの内訳が計測できないからである。もしも、アプリケーションAのみが実行されているときに、上記のように、アプリケーションAが60%、タスクAが50%、カーネル部分が10%と計測できていれば、引き算により、アプリケーションB、タスクB、カーネルのアプリケーションB部分を算出できる。
つぎに、暗号アルゴリズムネゴシエーション処理について以下で詳細に述べる。以下では、ネットワークカメラ12内の暗号情報決定部18と、通信装置24内の暗号情報決定部32のうち、ネゴシエーションを開始する側をイニシエータと呼び、イニシエータに対して応答する側をレスポンダと呼ぶ。
図3は、暗号アルゴリズムネゴシエーション処理のシーケンスを表している。図3で、まずイニシエータが、複数の暗号アルゴリズム(ここでは仮に暗号アルゴリズムa、b、cとする)の情報を含んだ提案パケットをレスポンダに対して送信する。レスポンダは、その提案パケットを受信すると、その中からひとつの暗号アルゴリズム(ここでは仮に暗号アルゴリズムbとする)を選択し、イニシエータに対して、選択した暗号アルゴリズムの情報を含んだ応答パケットを送信する。イニシエータは、レスポンダからの応答パケットを受信すると、そこに含まれている暗号アルゴリズム(暗号アルゴリズムb)を採用する。以上のようにして、イニシエータとレスポンダの両方で同じ暗号アルゴリズム(暗号アルゴリズムb)を使うことが約束され、暗号通信を行なえるようになる。
なお、イニシエータが提案する暗号アルゴリズムは1つでもよい。また、レスポンダは、提案された暗号アルゴリズムの中に利用可能な暗号アルゴリズムがなければ、応答しなくてもよい。また、通信装置24内の暗号情報決定部32が、イニシエータとして暗号アルゴリズムを提案したり、レスポンダとして暗号アルゴリズムを選択する際には、リソース監視部30から得たCPU使用率の情報を用いるが、その際の具体的な手順については後述する。
なお、暗号アルゴリズムを折衝する際のメッセージのやりとりは、図3のシーケンスに限定するものではなく、既存の鍵交換プロトコルの規定に則って行っても良い。例えば、一般的にIPsecと併用されることが多い鍵交換プロトコルIKE(Internet Key Exchange)を使って、規定のメッセージシーケンスの中で暗号アルゴリズムを折衝しても良い。
また、ここでは暗号アルゴリズムのネゴシエーションを、暗号通信を行なう前に一度だけ行なう例について説明したが、暗号通信の途中において暗号アルゴリズムをネゴシエーションし直してもよい。
次に、通信装置24内の暗号情報決定部32が、イニシエータとして、レスポンダに対して提案する暗号アルゴリズムを決定する手順や、レスポンダとして、イニシエータから提案された複数の暗号アルゴリズムの中からイニシエータに応答通知する暗号アルゴリズムを選択する手順について説明する。ところで、暗号アルゴリズムにはさまざまなものがあるが、それぞれによって暗号化復号化処理の負荷や、暗号の破られにくさを示す暗号強度が異なる。したがって、本実施の形態では、基本的には、ネットワークカメラ映像の暗号化に用いる暗号アルゴリズムとして、CPUに余裕のある場合にはできるだけ暗号強度の高いものを選択してセキュリティを高め、CPUに余裕のない場合にはCPUリソースが不足しないように処理負荷の低いものを選択する。
<通信装置24がレスポンダとなる場合>
さて、図4および図5は、通信装置24内の暗号情報決定部32がレスポンダとなる場合のフローチャートである。以下では、まず図4のフローチャートに沿って説明を行なう。
まず、通信装置24内の暗号情報決定部32(以下レスポンダ)は、暗号処理部38がサポートしている暗号アルゴリズムの集合Aを求める(S401)。ここで、ネットワークカメラ12内の暗号情報決定部18(以下イニシエータ)からの提案パケットを待つ状態になる。
イニシエータは、まずネゴシエーションの開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。イニシエータは、ネゴシエーション開始要求を受けると(S411)、ネゴシエーションを開始する。すなわち、1つもしくは複数の暗号アルゴリズムの提案を含むパケットをレスポンダに送信する(S412)。この提案パケットを受信したレスポンダでは、提案された暗号アルゴリズムの集合Bをパケットから読み取る(S402)。応答可能な暗号アルゴリズム(集合C)は、提案された暗号アルゴリズム(集合B)のうち暗号処理部38がサポートしているもの(集合A)であるので、C=A∩Bとして求められる(S403)。
さて、ここからレスポンダに対して応答する暗号アルゴリズムを選択するステップに入る(S500)。ステップS500の詳細は、図5のフローチャートを用いて説明する。
ここでの前提としては、CPUを利用するアプリケーションは、録画アプリケーション28とネットワークカメラアプリケーション34のみとする。またこの時点では、録画アプリケーション28だけがすでにCPUを利用しており、ネットワークカメラアプリケーション34はまだ起動されておらず、CPUを利用していないものとする。
まず、レスポンダは、リソース監視部30からCPU使用率CPUUtilを取得する(S501)。CPUUtilは、その時点で実行されているアプリケーションによるCPU使用率(アプリケーションが複数の場合はそれらの合計)を表す。ただし、既に述べたように、リソース監視部30が暗号情報決定部32に対して通知するCPU使用率には、その時刻の瞬間CPU使用率ではなく、ある程度平滑化されたCPU使用率(例えばその時刻までの一定時間の平均CPU使用率等)を用いる。この理由は、瞬間CPU使用率を利用すると、CPU使用率の一時的な変動の影響を大きく受けるため、一定時間利用する暗号アルゴリズムを選択する適切な判断基準とはなりえないからである。
次に、応答可能な暗号アルゴリズムの集合Cのなかで、以下の式(式1)を満たす暗号アルゴリズムの集合Dを求める(S502)。
CPURecord+CPUCamera(x)≦α ・・・(式1)
ここで、CPURecordは録画アプリケーション28が消費するCPUリソース、CPUCameraは暗号アルゴリズムxを用いて暗号通信を行ったときに、ネットワークカメラアプリケーション34が必要とするCPUリソースである。したがって、(式1)が満たされるということは、TV録画と、暗号アルゴリズムxによる暗号通信を同時に行っても、平均CPU使用率がα[%]以下となり、両方のタスクが正常に実行されることを意味している。αの値は、例えば95%などの値をあらかじめ設定しておく。暗号情報決定部32は、リソース監視部30から、複数の暗号アルゴリズムの各々について、暗号処理を行ったときにシステム全体で必要となるCPUリソースを計算するのに必要なCPU使用率をステップS501において取得して全処理負荷(CPURecord+CPUCamera(x))を推定する全処理負荷推定手順をステップS502において実施している。また、ステップS502において、(式1)を満たす暗号アルゴリズム(集合D)を求めるために、各々の暗号アルゴリズムについて、前記全処理負荷と、第1基準値であるαとを比較する比較手順を実施している。
図6は、集合Cの要素が暗号アルゴリズムa、b、cであった場合の例である。この場合、(式1)を満たす暗号アルゴリズム(集合D)は暗号アルゴリズムbと暗号アルゴリズムcである。
CPURecord、CPUCamera(x)の求め方は、先に述べたCPU使用率の考え方を用いると、以下のとおりとなる。まず、この時点でCPUを利用しているのは録画アプリケーション28だけであるので、CPURecord=CPUUtilとなる。また、CPUCamera(x)は、CPUCamera(x)=CPUCameraConst+CPUCameraEnc(x)として求められる。ここで、CPUCameraConstは、暗号処理以外の処理でネットワークカメラアプリケーション34が消費するCPUリソースであり、CPUCameraEnc(x)は暗号アルゴリズムxを用いたときに、暗号処理で消費するCPUリソースである。
CPUCameraEnc(x)は、アプリケーション層での通信速度に比例すると仮定すると、以下のようにして求められる。CPUCameraEnc(x)=(CameraRate/EncRate(x))×100[%]。ここで、CameraRateは、ネットワークカメラアプリケーション34が行なう通信のアプリケーション層での通信速度、EncRate(x)は、暗号アルゴリズムxを利用した暗号通信処理のみに、内蔵のCPUを100%利用したときのアプリケーション層での通信速度である。
ここで用いたCPUCameraConst、CameraRateの値は、計測するのではなく、システムから与えられているものとする。また図7のような暗号処理使用資源表46を、図2に示したように、暗号情報決定部32に設けておく。暗号処理使用資源表46には、各暗号アルゴリズムのEncRate(x)と共に、それぞれの暗号強度の順位が格納されている。これにより暗号アルゴリズムxからEncRate(x)を求めることができる。
なお、ここではネットワークカメラアプリケーション34がまだ開始されていない場合について説明したが、ネットワークカメラアプリケーション34が既に開始されており、暗号アルゴリズムとしてzが用いられていた場合には、CPURecord=CPUUtil−CPUCamera(z)のように、録画アプリケーション28に必要なCPUリソースを求めることができる。また、CPURecordの値がシステムから与えられている場合には、その値を用いることもできる。また、CPURecordを、以前にこのCPU上で録画アプリケーション28のみが実行されていた期間の平均CPU使用率としてもよい。また、CPUCamera(x)を、以前にこのCPU上で暗号アルゴリズムxを用いたネットワークカメラアプリケーション34のみが実行されていた期間の平均CPU使用率としてもよい。その場合、これらのCPU使用率情報を、図2のCPU使用率情報メモリ44に格納しておく。
なお、CPURecord(%)は、(TV録画での平均使用CPU資源(メガインストラクション/秒:MIPS)/CPUの能力(MIPS))*100(%)と言い換えることができる。また、CPUCameraConst(%)は、(カメラアプリケーションでの平均使用CPU資源(MIPS)/CPUの能力(MIPS))*100と言い換えることができる。CameraRate(Mbps)は、カメラアプリケーションの平均データ転送量と言い換えることができる。また、EncRate(x)(Mbps)は、最大CPU資源(MIPS)/暗号アルゴリズムxで1Mbpsのデータを暗号化するのに必要な平均CPU資源(MIPS/Mbps)と言い換えることができる。
次に、集合Dが空集合かどうか、すなわち(式1)を満たす暗号アルゴリズムが存在するかどうかを判定する(S503)。空集合の場合、つまり(式1)を満たす暗号アルゴリズムが存在しない場合は、どの暗号アルゴリズムを用いてもCPUリソースが不足することを示しているため、できるだけCPU処理負荷を軽減するために、応答可能な暗号アルゴリズム(集合C)のうち最も処理負荷の低いものを選択する(S505)。
一方、集合Dが空集合でない場合は、その中で最も暗号強度の高い暗号アルゴリズムを選択する(S504)。図6の例では、集合Dに含まれる暗号アルゴリズムb、cのうち、暗号強度のより高い暗号アルゴリズムbが選ばれる。暗号アルゴリズムの処理負荷や暗号強度の情報は、図7の暗号処理使用資源表46から得ることができる。ステップS503とステップS504においては、前記全処理負荷が前記第1基準値を下回る、ひとつもしくは複数の暗号アルゴリズムを選択する選択手順を実施していることになる。
なお、本実施の形態では集合Dが空集合の場合に、集合Cのうち最も処理負荷の低い暗号アルゴリズムを応答通知するとしたが、この場合にはCPUの処理能力を超えてしまう場合があるので、録画アプリケーション28を優先する場合には、応答パケットをイニシエータに送信せずに、ネットワークカメラアプリケーション34を開始しない、もしくは既に開始している場合には中断することもできる。また、カメラ映像を間引いて画質を落として伝送するようにしてもよい。
以降は再び図4を用いて説明する。レスポンダは、ステップS500で選択した暗号アルゴリズムの情報を含む応答パケットをイニシエータに対して送信する(S404)。
次に、レスポンダは、応答通知した暗号アルゴリズムを実際に利用するために、暗号処理部38にその暗号アルゴリズムを設定する(S405)。一方、イニシエータは、レスポンダからの応答パケットを受信し(S413)、応答通知された暗号アルゴリズムをネットワークカメラ12内の暗号処理部16に設定する(S414)。
このあと、ネットワークカメラ12は、撮影部14で撮像した映像データを、暗号処理部16において、設定された暗号アルゴリズムの暗号化機能を使用して暗号化データとし、暗号情報決定部18に設定された暗号アルゴリズムの識別子、または暗号アルゴリズムと鍵とを特定するセキュリティアソシエーションと呼ばれる情報SAの識別IDを添付する。そして、この暗号化データは、パケットとして通信処理部20を通じてインターネット22に送出される。通信装置24の通信処理部36は、パケットを受信し、添付された暗号アルゴリズムの識別子、またはSAの識別IDをもとに、折衝、合意した暗号アルゴリズムを使用して暗号処理部38において暗号の復号化を行ない、その結果得られた映像データをディスプレイ40に表示する。
<通信装置24がイニシエータとなる場合>
次に、通信装置24内の暗号情報決定部32がイニシエータとなり、ネットワークカメラ12内の暗号情報決定部18とネゴシエーションを行なう場合の手順を示す。また、図8および図9は、このときの動作手順を示すフローチャートである。以下では、まず、図8のフローチャートに沿って説明を行なう。
まず、通信装置24内の暗号情報決定部32(以下イニシエータ)は、暗号処理部38がサポートしている暗号アルゴリズムの集合Aを求める(S801)。そしてイニシエータは、ネゴシエーション開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。
イニシエータは、ネゴシエーションの開始要求を受け付けると(S802)、CPU使用率を用いて暗号アルゴリズムを選択する(S900)。ステップS900の詳細な手順は、図9のステップS901〜S905に示すように、通信装置24がレスポンダの場合(図4のステップS500、すなわち図5)とほぼ同じであるので、ここでは説明を省略する。異なるのは、暗号アルゴリズムを選択する集合が、応答通知可能な暗号アルゴリズム(集合C)か、サポートしている暗号アルゴリズム(集合A)かの違いのみである。
次に、イニシエータは、選択した暗号アルゴリズムをレスポンダに対して提案する(S803)。
レスポンダでは、はじめに暗号処理部16がサポートしている暗号アルゴリズムの集合Eを求めておく(S811)。その後、イニシエータから提案パケットを受信すると(S812)、提案された暗号アルゴリズムを暗号処理部16がサポートしているか(すなわち提案された暗号アルゴリズムが集合Eに含まれているか)を判断する(S813)。提案された暗号アルゴリズムを暗号処理部16がサポートしていない(すなわち提案された暗号アルゴリズムが集合Eに含まれていない)場合は、イニシエータに応答を返すことができないのでネゴシエーションに失敗し、次の提案パケットを待つ。提案された暗号アルゴリズムを暗号処理部16がサポートしている(すなわち提案された暗号アルゴリズムが集合Eに含まれている)場合には、その暗号アルゴリズムをイニシエータに対して応答通知し(S814)、応答通知した暗号アルゴリズムを暗号処理部16に設定する(S815)。
イニシエータでは、応答パケットを受信すると(S804)、応答通知された暗号アルゴリズムを暗号処理部38に設定する(S805)。
以上のように、本実施の形態によれば、イニシエータに対して応答通知する、もしくはレスポンダに対して提案する暗号アルゴリズムを選択する際に、CPUリソースが不足しない範囲で暗号強度の最も高いものを選択することができる。よって、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション34のような暗号通信を必要とするアプリケーションとTV録画のようなその他の処理とを並行して行ったときのCPUリソースの不足を防ぐことができる。
なお、本実施の形態ではレスポンダに対して提案する暗号アルゴリズムは1つであるとしたが、優先順位を低くしておけば、他の暗号アルゴリズムを複数提案してもよい。
また、本実施の形態ではネットワークカメラアプリケーション34以外のアプリケーションはTV録画のみとしていたが、TV録画以外の他のアプリケーションが存在した場合には、上述の「CPURecord」を、「暗号アルゴリズムネゴシエーションの対象となる暗号通信以外の全てのアプリケーションが使用するCPU使用率の合計」として読み替えることで、同様の処理が可能である。
また、本実施の形態の説明中で「ネットワークカメラアプリケーション34が既に開始されており、暗号アルゴリズムとしてzが用いられていた場合には、CPURecord=CPUUtil−CPUCamera(z)のように、録画アプリケーション28に必要なCPUリソースを求めることができる。」と記載したが、CPUUtilがα[%]を越えていた場合には、この方法ではCPURecordを小さく見積もっていることになり(その理由は後述する)、その結果、ステップS502、S902で選択した暗号アルゴリズムを用いて暗号通信を行っても、CPU利用率がα[%]を越えてしまう可能性がある。このような問題を回避するために、ステップS501、S901で取得したCPU使用率がα[%]を越えていた場合には、集合C(レスポンダの場合)もしくは集合A(イニシエータの場合)のうち最も処理負荷の低い暗号アルゴリズムを選択してもよい。
「CPUUtilがα[%]を越えている」とは、CPUUtilを計測したときに、録画アプリケーション28が必要なCPUリソースを完全には確保できていないことを意味する。具体的な例で説明する。TV録画をするのに必要なCPUリソースであるCPURecordが80%であるとする。また、暗号アルゴリズムzを利用した場合に、ネットワークカメラアプリケーション34が必要とするCPUリソースであるCPUCamera(z)が40%であったとする。また、α=95%とする。CPUがTV録画とネットワークカメラアプリケーション34(暗号処理を含む)を実行している場合、必要なCPUリソースは、80%+40%=120%となるが、CPU使用率が100%を越えることはないので、CPU使用率の計測値CPUUtilは、このとき、100%に近い値(α=95%を越える値、例えば98%)として計測される。このとき、TV録画やネットワークカメラアプリケーション34は正常に動作できていない状態にある。このような状態で計測したCPUUtilをもとにCPURecordを計算すると、CPURecord=CPUUtil−CPUCamera(z)は、98%−40%=56%となる。正しくは80%であるべきところを56%と誤って計算してしまう。すなわち、CPURecordを実際よりも小さく見積もってしまうことになる。ここで、例えばCPUCamera(y)=30%となる暗号アルゴリズムが存在した場合、CPURecord+CPUCamera(y)=56%+30%=86%<95%(α)となり、暗号アルゴリズムyを選択することができる。しかし、TV録画をするのに本当に必要なCPUリソースは80%であるので、TV録画およびネットワークカメラアプリケーション34を実行するのに本当に必要なCPUリソースは、80%+30%=110%>αとなってしまい、やはり正常に動作することができない。いいかえると、CPUUtil>αと計測された場合は、その時点で実行されているアプリケーションに対して十分なCPUリソースが割り当てられているとは限らないということになる。よって、CPUUtil>αと判定され、正常な動作ができていないと推定される場合には、本当のCPURecordを求めることができず、適切な暗号アルゴリズムの選択ができないので、暗号アルゴリズムを変更した後に正常な動作をする可能性が比較的高い、最も処理負荷の低い暗号アルゴリズムを選択してもよいのである。もちろん、最も処理負荷の低い暗号アルゴリズムを選択したからといって、正常に動作するようになるという保証は、必ずしもないので、その場合は、異常動作を報告するモードに移るようにしてもよい。このモードにおいて、不要不急のアプリケーションの処理を一時停止するかその処理速度を遅くして、必要なCPUリソースを確保するなどの処理を行なえばよい。
(実施の形態2)
次に実施の形態2について説明する。ただし、全体のシステム構成など、実施の形態1と変わらない部分の説明はここでは省略し、実施の形態1の図面を援用する。実施の形態1と異なるのは、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態2では、実施の形態1と違い、ネットワークカメラアプリケーション34を実行するのに必要なCPUリソースが分からない場合にでも適用できる方法を説明する。
<通信装置24がレスポンダとなる場合>
図10および図11は、通信装置24内の暗号情報決定部32がレスポンダとなる場合のフローチャートである。以下では、まず図10のフローチャートに沿って説明を行なう。
まず、通信装置24内の暗号情報決定部32(以下レスポンダ)は、暗号処理部38がサポートしている暗号アルゴリズムの集合Aを求める(S1001)。こうして、ネットワークカメラ12内の暗号情報決定部18(以下イニシエータ)からの提案パケットを待つ状態になる。
イニシエータは、まずネゴシエーションの開始要求を受け付け(S1011)、ネゴシエーションを開始する。すなわち、1つもしくは複数の暗号アルゴリズムの提案を含むパケットをレスポンダに送信する(S1012)。この提案パケットを受信したレスポンダでは、提案されたアルゴリズムの集合Bをパケットから読み取る(S1002)。レスポンダが応答通知可能な暗号アルゴリズム(集合C)は、イニシエータによって提案された暗号アルゴリズム(集合B)のうち、暗号処理部38がサポートしているもの(集合A)であり、C=A∩Bとして求められる(S1003)。
次に、レスポンダは、集合Cから暗号アルゴリズムを選択する(S1100)。図11のフローチャートを用いてこのステップS1100の詳細を説明する。
まず、レスポンダは、この暗号アルゴリズムネゴシエーションが暗号通信開始前のものかどうかを判断する(S1104)。暗号通信開始前の場合は、暗号強度よりもCPU負荷を軽減することを優先して、集合Cのうち最も処理負荷の低い暗号アルゴリズムを応答通知する(S1102)。
暗号通信を既に開始している場合には、そのときのCPU使用率に応じて、レスポンダは応答通知する暗号アルゴリズムを切り替える。まず、リソース監視部30から、現状態での、すなわち現在使用中の暗号アルゴリズムなどを含めたCPU使用率CPUUtilを取得する(S1103)。次に、暗号アルゴリズムを切り替える際の閾値として、2つの値γ[%]とδ[%](γ≧δ)を用いる。γ、δの値は例えば90[%]、70[%]などとあらかじめ決めておく。そして、δ<CPUUtil<γの場合には、CPU使用率が高すぎず低すぎず適当であると判断し、現在使用している暗号アルゴリズムを選択する(S1104、S1108、S1107)。
CPUUtil≧γの場合(S1104)は、レスポンダは、CPU負荷が高すぎると判断し、現在使用している暗号アルゴリズムよりもCPU負荷が低い暗号アルゴリズムを選択する。ただし、できるだけ強固な暗号アルゴリズムを使用するために、現在使用している暗号アルゴリズムよりもCPU負荷が低い暗号アルゴリズムがある場合には、その中で最も暗号強度の高いものを選択する(S1105、S1106)。現在使用している暗号アルゴリズムが集合Cのうち最も負荷の低いものだった場合には、その暗号アルゴリズムを選択する(S1105、S1107)。
CPUUtil≦δの場合(S1104、S1108)は、レスポンダは、CPUリソースに余裕があると判断し、現在使用している暗号アルゴリズムよりも暗号強度の高い暗号アルゴリズムがある場合には、その暗号アルゴリズムを選択する(S1109、S1110)。ただし、CPU負荷が突然高くなるのを防ぐため、現在使用している暗号アルゴリズムよりも暗号強度が高い暗号アルゴリズムの中で最も処理負荷の低い暗号アルゴリズムを選択する。現在使用している暗号アルゴリズムが集合Cのうち最も暗号強度の高いものだった場合には、その暗号アルゴリズムを選択する(S1109、S1107)。
ステップS1103においては、暗号処理実行中の任意の時刻に、その時点までの一定期間に測定したCPU使用率の平均値を求める手順により、あらかじめCPU使用率CPUUtilが求められているものとする。また、このステップS1103においてCPU使用率CPUUtilを求めるようにしてもよい。ステップS1104は、CPU使用率と第2基準値γとを比較する手順を実施している。ステップS1105とステップS1106は、その比較の結果、CPU使用率が第2基準値よりも高い場合に、その時点で使用している暗号アルゴリズムよりも負荷の低い一つもしくは複数の暗号アルゴリズムを選択する手順を実施している。
ステップS1106、ステップS1109、ステップS1110では、暗号強度に基づいて暗号アルゴリズムの選択を行なうが、このために、これらのステップの前またはその中で、暗号強度の順序を求める手順を実行する。図7の暗号処理使用資源表46には、各暗号アルゴリズムのEncRate(x)と共に、暗号強度データとして各暗号アルゴリズムの暗号強度の順位が格納されている。この暗号強度データを参照することにより、暗号強度に基づく暗号アルゴリズムの選択が容易に可能となる。
ステップS1108は、CPU使用率と第3基準値δとを比較する手順である。ステップS1109、ステップS1110は、CPU使用率が第3基準値よりも低い場合において、その時点で使用している暗号アルゴリズムよりも暗号強度の高い一つもしくは複数の暗号アルゴリズムを選択する手順を実施している。
ステップS1104とステップS1108で、CPU使用率と第2基準値γおよび第3基準値δとを比較し、CPU使用率が第2基準値γより低く第3基準値δより高い場合は、ステップS1107において、その時点で使用している暗号アルゴリズムを選択する手順を実施することになる。
以降は再び図10に戻って説明する。まず、レスポンダは、ステップS1100で選択した暗号アルゴリズムをイニシエータに対して応答通知する(S1004)。
次に、応答通知した暗号アルゴリズムを実際に利用するために、暗号処理部38にその暗号アルゴリズムを設定する(S1005)。一方、イニシエータでは、レスポンダからの応答パケットを受信し(S1013)、応答通知された暗号アルゴリズムをネットワークカメラ12内の暗号処理部16に設定する(S1014)。
<通信装置24がイニシエータとなる場合>
次に、通信装置24内の暗号情報決定部32がイニシエータとなり、ネットワークカメラ12内の暗号情報決定部18とネゴシエーションを行なう場合の手順を示す。また、図12および図13は、このときの動作手順を示すフローチャートである。以下では、まず、図12のフローチャートに沿って説明を行なう。
まず、通信装置24内の暗号情報決定部32(以下イニシエータ)は、暗号処理部38がサポートしている暗号アルゴリズムの集合Aを求める(S1201)。そしてイニシエータは、ネゴシエーション開始要求を待つ。ネゴシエーションの開始要求は、暗号通信を開始する際や、前回のネゴシエーションから一定時間経過後や、ネゴシエーション開始コマンドを実行したときなどに発行される。
イニシエータは、ネゴシエーションの開始要求を受け付けると(S1202)、CPU使用率を用いて暗号アルゴリズムを選択する(S1300)。ステップS1300の詳細な手順は、図13のステップS1301〜S1310に示すように、通信装置24がレスポンダの場合(図10のS1100、すなわち図11)とほぼ同じであるので、ここでは説明を省略する。異なるのは、暗号アルゴリズムを選択する集合が、応答通知可能な暗号アルゴリズム(集合C)か、サポートしている暗号アルゴリズム(集合A)かの違いのみである。
そして、イニシエータは、選択した暗号アルゴリズムをレスポンダに対して提案する(S1203)。
レスポンダでは、はじめに暗号処理部16がサポートしている暗号アルゴリズムの集合Eを求めておく(S1211)。その後、イニシエータから提案パケットを受信すると(S1212)、提案されたアルゴリズムを暗号処理部16がサポートしているか(すなわち提案された暗号アルゴリズムが集合Eに含まれているか)を判断する(S1213)。提案された暗号アルゴリズムを暗号処理部16がサポートしていない(すなわち提案された暗号アルゴリズムが集合Eに含まれていない)場合は、イニシエータに応答を返すことができないのでネゴシエーションに失敗し、次の提案パケットを待つ。提案された暗号アルゴリズムを暗号処理部16がサポートしている(すなわち提案された暗号アルゴリズムが集合Eに含まれている)場合には、その暗号アルゴリズムをイニシエータに対して応答通知し(S1214)、応答通知した暗号アルゴリズムを暗号処理部16に設定する(S1215)。
イニシエータでは、応答パケットを受信すると(S1204)、応答通知された暗号アルゴリズムを暗号処理部38に設定する(S1205)。
以上のように、本実施の形態によれば、イニシエータに対して応答通知する、もしくはレスポンダに対して提案する暗号アルゴリズムを選択する際に、CPU使用率に応じて、現在使用している暗号アルゴリズムをより適切な暗号アルゴリズムに切り替えることができる。よって、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション34のような暗号通信を必要とするアプリケーションと、TV録画のようなその他の処理を並行して行ったときの、CPUリソースの不足を防ぐことができる。
なお、本実施の形態ではレスポンダに対して提案する暗号アルゴリズムは1つであるとしたが、優先順位を低くしておけば、他の暗号アルゴリズムを複数提案してもよい。
(実施の形態3)
次に実施の形態3について説明する。ただし、全体のシステム構成など、実施の形態1と変わらない部分の説明はここでは省略し、実施の形態1の図面を援用する。実施の形態1と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態3では、通信装置24において定期的にCPU使用率の変化を検知し、あらかじめ定められたタイミングではなく、CPU使用率が変化したタイミングで、通信装置24内の暗号情報決定部32がイニシエータとなり、ネットワークカメラ12内の暗号情報決定部18とネゴシエーションを行なう。
また、図14および図15は、実施の形態3の動作手順を示すフローチャートである。以下では、まず図14のフローチャートに沿って説明を行なう。
まず、暗号情報決定部32は、暗号処理部38がサポートしている暗号アルゴリズムの集合Aを求める(S1401)。また、暗号情報決定部18は、暗号処理部16がサポートしている暗号アルゴリズムの集合Eを求める(S1421)。
次に、暗号通信開始前に、暗号情報決定部32、18の間で、実施の形態1の手順に従って暗号アルゴリズムのネゴシエーションを行なう(S1402、S1422)。そして、このネゴシエーションに従って選択された暗号アルゴリズムを用いて暗号通信が開始される。このとき、暗号情報決定部32は、この時点でのCPU使用率をpreCPUUtilとして保持しておく。なお、ここではどちらがイニシエータとなってネゴシエーションを行ってもよい。
さて、その後暗号通信を継続する間、暗号情報決定部32は、定期的にリソース監視部30からCPU使用率CPUUtilを取得する(S1403)。そして、前回ネゴシエーション時のCPU使用率preCPUUtilとの差分CPUdiffを次のように計算する。
CPUdiff=CPUUtil−preCPUUtil
ここで、暗号情報決定部32は、CPUUtilとpreCPUUtilとの差が、ある一定値β[%]よりも大きいかどうかを、次の不等式が成り立つどうかで判定する(S1404)。
|CPUdiff|≧β
なお、βの値は、例えば5%のようにあらかじめ定めておく。この式が成り立たないとき、つまり前回のネゴシエーション時にくらべてCPU使用率の変化がβ[%]未満である場合は、暗号情報決定部32は、暗号アルゴリズムを変更する必要はないと判断し、ネゴシエーションを行なわない。
上記の不等式が成り立つとき、つまり、前回のネゴシエーション時にくらべてCPU使用率の変化がβ[%]以上であるときは、暗号情報決定部32は、暗号アルゴリズムを変更する必要があるかもしれないと判断し、使用すべき暗号アルゴリズムを求める(S1500)。ステップS1500の詳細な手順は、図15のステップS1501〜S1506に示すように、実施の形態1の通信装置24がイニシエータの場合(図8のS900、すなわち図9)とほぼ同じであるので、ここでは説明を省略する。異なるのは、提案パケットを必ず送信するのか、暗号アルゴリズムが変更となるときにだけ送信するのかの違いのみである(S1503、S1505)。その結果、暗号アルゴリズムを変更する必要がある場合は、暗号情報決定部32は、イニシエータとして、提案パケットをレスポンダに対して送信する(S1405)。
次に、レスポンダは、受信した提案パケットに対して、応答パケットを送信し(S1423〜S1425)、応答通知した暗号アルゴリズムを暗号処理部16に設定する(S1426)。また、イニシエータは、応答パケットを受信すると(S1406)、応答通知された暗号アルゴリズムを暗号処理部38に設定する(S1407)。以上の手順(S1406、S1407、S1423〜S1426)は、実施の形態1の通信装置24がイニシエータの場合(図8のS804、S805、S812〜S815)と全く同じであるので、詳細な説明は省略する。
最後に、次回のステップS1403でCPU使用率の変化を計算するために、ここでのCPU使用率CPUUtilの値をpreCPUUtilに設定する(S1408)。
以上のように、本実施の形態によれば、できるだけ強固なセキュリティを保ちつつ、ネットワークカメラアプリケーション34のような暗号通信を必要とするアプリケーションと、TV録画のようなその他の処理を並行して行ったときの、CPUリソースの不足を防ぐことができる。また、CPU使用率に変化が起こったときに暗号アルゴリズムの見直しが行われるため、柔軟にかつ効率的に、最適な暗号アルゴリズムを選択することができる。
なおここではβの値は一定値としているが、現在使用している暗号アルゴリズムや、その他の集合Aに含まれる暗号アルゴリズムが必要とするCPUリソース等に基づいてβ値を動的に変化させてもよい。たとえば、複数の暗号アルゴリズムの各CPU使用率間の差に比べてβ値が小さいと、その時のCPU使用率の変化が少しであってもその変化量はβ値を超えるのでステップS1500の選択判定を開始することになるが、暗号アルゴリズムを変更するほどのCPU使用率の余裕がないことが分かり、選択判定が無駄になる。選択中の暗号アルゴリズムとCPU使用率において隣接するアルゴリズムとのCPU使用率の差値をβ値とし、選択中の暗号アルゴリズムによってβ値を動的に変えるようにすれば、無駄な処理を削減できる。
(実施の形態4)
次に実施の形態4について説明する。ただし、全体のシステム構成など、実施の形態1と変わらない部分の説明はここでは省略し、実施の形態1の図面を援用する。実施の形態1と異なるのは、暗号アルゴリズムのネゴシエーションを行なうタイミングと、暗号アルゴリズムを選択する手順のみであるので、その部分について以下で説明する。
実施の形態4では、通信装置24内の暗号情報決定部32とネットワークカメラ12内の暗号情報決定部18とが、暗号アルゴリズムネゴシエーション時に複数の暗号アルゴリズムを合意しておく。そして、暗号化側でパケットを送信する際に、合意した暗号アルゴリズムのうちのどの暗号アルゴリズムを用いて送信パケットの暗号化を行っても、復号化側では正しく復号できるようにする。
以下では、CPU使用率にもとづいて暗号アルゴリズムを選択し、その暗号アルゴリズムを用いて送信パケットを暗号化する側の動作手順と、その相手側の動作手順をそれぞれ示す。
図16および図17は、実施の形態4の動作手順を示すフローチャートである。図16の左側および図17は、CPU使用率に基づいて暗号アルゴリズムを選択する側(ここでは通信装置24内の暗号情報決定部32とする)の動作手順を、図16の右側は、相手側(ここではネットワークカメラ12内の暗号情報決定部18とする)の動作手順を示している。以下では、まず図16のフローチャートに沿って説明を行なう。
<暗号アルゴリズム選択側の動作手順>
まず、暗号アルゴリズム選択側の動作手順について説明する。暗号アルゴリズム選択側は、暗号アルゴリズム被通知側と暗号アルゴリズムネゴシエーションを行なう(S1601)。このとき、通信相手と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。ここで合意した暗号アルゴリズムの集合を集合Fとする。
次に、パケット送信要求が発生するまで待つ(S1602)。パケット送信要求が発生すると、CPU使用率から使用すべき暗号アルゴリズムを選択する(S1700)。なお、ステップS1700の暗号アルゴリズム選択方法の詳細は、図17のステップS1701〜S1705に示すように、実施の形態1におけるアルゴリズム選択方法(図4のS500、図5)とほぼ同じであるので、ここでは説明を省略する。実施の形態1におけるアルゴリズム選択方法と異なるのは、選択肢となる暗号アルゴリズムの集合が、集合Cであるか、集合Fであるかの違いのみである。
なお、ここではパケット送信ごとに使用する暗号アルゴリズムを選択するとしているが、複数のパケット毎に、あるいは、一定時間おきに選択するようにしてもよい。
最後に、選択した暗号アルゴリズムで送信パケットを暗号化し送信して(S1603)、パケット送信要求を受け付ける状態に戻る(S1602)。
ステップS1602において受け付けるパケット送信要求は、ネットワークカメラ12を制御するための指示をネットワークカメラ12に送信する場合のようにアプリケーションの動作により発生するものや、IPレイヤなどでのプロトコルの動作により発生するものなどがありうる。典型的な例は、通信装置24に設けられた操作ボタンを使用者が押すことにより、通信装置24においてカメラアプリケーションが動作し、このカメラアプリケーションがネットワークカメラ12に対して映像データパケットの送信を要求する場合である。また、同時に、通信制御用パケットや暗号アルゴリズムネゴシエーションパケットなどを暗号化する場合もある。
ステップS1603では、ステップS1602においてその送信要求を受け付けたパケットを暗号化して送信する。
なお、ステップS1603で送信した暗号パケットをネットワークカメラ12において復号化する場合は、暗号パケットに付属するSA識別ID(SPI)を参照して、そのパケットがどの暗号アルゴリズムによって暗号化されているかを判別し、暗号の復号化を行なう。このステップは、図16のフローチャートの中で行なってもよいし、受信パケットの暗号解読のフローチャートにしたがって行なってもよい。
<相手側の動作手順>
次に、相手側の動作手順について説明する。まず、相手側は、暗号アルゴリズム選択側と暗号アルゴリズムネゴシエーションを行なう(S1621)。このとき、暗号アルゴリズム選択側と複数の暗号アルゴリズムを合意し、その全ての暗号アルゴリズムの暗号化鍵、復号化鍵を生成しておく。そして、通信装置24から暗号化されたパケットを受信したかどうかを判定し(S1622)、この判定結果がYESの場合は、このパケットに適用されている暗号アルゴリズムを、暗号処理部16で使用する暗号アルゴリズムとして設定する(S1623)。
次に、パケット送信要求が発生しているかをチェックする(S1624)。パケット送信要求が発生していれば、ステップS1623で設定された暗号アルゴリズムを用いて送信パケットを暗号化し、送信する(S1625)。
なお、ステップS1625で送信したパケットを通信装置24が受信するには、通信装置24で実行されるステップS1603とステップS1602の間に、暗号化データのパケットを受信したかどうかの判断を行ない、受信した場合に暗号解読を行なうステップを付け加えてもよい。また、このフローチャートの手順とは別に、通信装置24が、暗号化データのパケット受信とその解読を行なう手順を割り込みなどを契機に行なうようにしてもよい。
以上のように、本実施の形態によれば、暗号アルゴリズム選択側と相手側とで、予め複数の暗号アルゴリズムを利用することを合意するため、暗号アルゴリズム選択側が、使用する暗号アルゴリズムを変更するときに、暗号アルゴリズムを折衝し直す必要がない。よって、より柔軟にCPU負荷を制御することができる。
ところで、実施の形態4においては、CPUリソースに余裕があった場合、通信装置24において、それまで使われていた暗号アルゴリズムよりも負荷の高い暗号アルゴリズムが選択され、ネットワークカメラ12に通知される。しかしながら、その通知の直後に通信装置24においてCPU使用率が何らかの理由のために増加した場合に、CPU使用率が増加する直前にネットワークカメラ12で暗号アルゴリズムxによって暗号化されたカメラ映像パケットを受信した通信装置24では、CPUリソースが不足しているためにこのパケットを復号化できない危険がある。このような危険を防止するために、暗号アルゴリズムを使用して通信している場合は、通信装置24において、CPUリソースの消費を増やすようなアプリケーションの追加や変更を暗号通信が終わるまで禁止するか、その危険をOSやユーザに知らせて適切な処理を行なうようにすればよい。このような危険防止の処理は、本発明の他の実施の形態においても適用できる。
なお、上記実施の形態1〜4では、各アプリケーションによるCPU使用率の推定値が必要になったときにリソース監視部30からその推定値を入手するとした。ところで、通信装置24において実行される可能性のある各種アプリケーションのうち、どのアプリケーションが同時並行して実行されるかが予め分かっている場合が多い。そのようなアプリケーションについては、それぞれ予め単独で実行してみて、リソース監視部30によりそのときのCPU使用率をそれぞれ計測し、計測した値を既定の値としてCPU使用率情報メモリ44に格納しておき、この既定の値を折衝時に取り出して使用するようにしてもよい。また、同じ組み合わせで実行される可能性のある2つ以上のアプリケーションについて、予め試験的に同時に実行してCPU使用率を計測したり、過去に同じ組み合わせで実行されている期間のCPU使用率を計測したりし、この計測結果を既定の値としてCPU使用率情報メモリ44に格納しておき、この既定の値を折衝時に取り出して使用するようにしてもよい。また、通信装置24の設計時に各アプリケーションによるCPU使用率を算出し、その算出結果を既定の値としてCPU使用率情報メモリ44に格納しておいてもよい。
また、CPU使用率の仕組みと計測方法については、採用するCPUが適用している仕組みと計測方法に従えばよく、上記説明の例に限定されることはない。
また、本実施の形態では、暗号アルゴリズム選択側が用いた暗号アルゴリズムを、相手側は、暗号アルゴリズム選択側から受信した暗号化パケットに基づいて判断するとしたが、これに替えて、暗号アルゴリズム選択側が、暗号アルゴリズム選択側で用いた暗号アルゴリズムを通知するためのパケットを別途相手側へ送信するようにしてもよい。また、この場合、相手側は、暗号アルゴリズム選択側から通知された暗号アルゴリズムを用いて、暗号アルゴリズム選択側へ送信すべきパケットを暗号化してもよい。
また、上記実施の形態1〜4においては、録画機能を有する通信装置24における暗号アルゴリズムの選択方法について説明したが、録画機能以外の機能を有する通信装置に対しても本発明を適用できることは言うまでもない。また、通信相手の機器(ネットワークカメラに限らない)も本発明のネゴシエーションの仕組みを有し、その機器内部でのCPU使用率に従って適用可能な複数のアルゴリズムを選択しながら、両者間でネゴシエーションを行なうことによって最終的に使用するアルゴリズムを選択するようにしてもよい。
(実施の形態5)
図18は、本発明の実施の形態5に係わる通信装置の構成を示すブロック図である。図18を参照すると、通信装置は、スケジュール部64、アプリケーション60、62、暗号通信アプリケーション70、72、暗号情報決定部74、通信処理部78、暗号処理部80、リソース監視部82を備えている。以下、本通信装置は、図1に示した通信装置24と同様に、TV受信、TV録画、録画番組の再生、カメラ映像の暗号通信による受信と表示等の機能を有するものとして説明する。
スケジュール部64は、リモコンや外部からの予約指令に従って、各アプリケーションの予約の登録、実行時刻の管理と実行の制御を行なう。アプリケーション60は、一例として、テレビ放送を受信して得られた映像データをハードディスクメモリに録画し、タイムシフトして再生するアプリケーション(図1の録画アプリケーション28に相当)であり、アプリケーション名をAとする。テレビ放送の録画をタスクaとし、タイムシフト再生をタスクcとする。暗号通信アプリケーション70は、一例として、ネットワークカメラから送られるカメラ映像データを復号化してディスプレイに表示するアプリケーション(図1のネットワークカメラアプリケーション34に相当)であり、アプリケーション名をBとする。アプリケーションBは、タスクbより成り、暗号アルゴリズムを使用する。
暗号情報決定部74は、使用する暗号アルゴリズムのネゴシエーションにおける、暗号アルゴリズムの選択・提案・決定に必要な各種情報(例えば、各暗号アルゴリズムが消費する使用資源情報、暗号強度情報など)、および暗号通信に必要な各種情報(例えば、暗号化・復号化に使用する公開鍵、秘密鍵、共有鍵などの鍵に関する情報など)を管理し、使用する暗号アルゴリズムを選択・決定する。
暗号処理部80は、複数の暗号アルゴリズム処理手段(あるいは暗号アルゴリズム処理手順を実行するプログラム)を備えており、ネゴシエーションパケットの処理や、暗号化・復号化に使用する鍵・公開値・公開鍵・秘密鍵・共有鍵などの作成や、送信するデータの暗号化や、受信したデータの復号化などを行なう。
通信処理部78は、暗号処理部80が作成したパケットをインターネット回線網に所定の通信プロトコルの形式にして送信し、インターネット回線網から受信した通信プロトコルの形式のデータからパケットを取り出して暗号処理部80に渡す。
次に、本実施の形態の通信装置の動作について説明する。
まず、TV録画を行なう際の動作について説明する。図18の通信装置において、受像部(図示しない)は、TV放送データを受信し、続いて、受信されたTV放送データを、アプリケーション60が、通信装置内蔵の蓄積媒体(図示しない)に記録する。この処理は、アプリケーション60中のタスクaの処理を本通信装置内蔵のCPUが実行することにより実現される。録画したいチャンネルのTV番組の放送開始時刻から放送終了時刻まで録画を連続的に行なうことで、TV録画が完了する。
TV録画の予約は、使用者が予めリモコンを用いて録画チャンネル番号・録画開始時刻・録画終了時刻を指示し、その指示内容をスケジュール部64が受取って、後述するスケジュール・使用資源表66に登録することにより行われる。
また、アプリケーション60は、録画したTV番組をタイムシフトして再生する機能(タスクc)を含んでいる。このタイムシフト再生のタスクcについても、リモコン予約により再生番組番号・再生開始時刻・再生終了時刻が指示され、その指示内容がスケジュール部64によりスケジュール・使用資源表66に登録される。
次に、ネットワークカメラの映像をディスプレイに表示する際のシステムの動作について説明する。この処理は、暗号通信を行なうための前処理と、実際にネットワークカメラアプリケーションを動作させる処理の2つに分かれる。暗号通信を行なうための前処理については後述し、はじめに、実際にネットワークカメラアプリケーションを動作させる処理の概要について述べる。ネットワークカメラ側の処理は、図43や、実施の形態1(図1)で説明したのでここでは説明を省略する。図18の通信装置では、通信処理部78でインターネット回線網から映像データに基づく暗号化パケットを受信し、暗号処理部80で復号化し、復号化された映像データを暗号通信アプリケーション70に渡し、暗号通信アプリケーション70は、映像データを所定の位置・大きさでディスプレイ(図示しない)に出力する。そして、ディスプレイが映像を表示する。以上のようにして、ネットワークカメラで撮影された映像がディスプレイに表示される。
ネットワークカメラの映像データを受信する時間帯の予約指示も、予めリモコンからスケジュール部64に対して行なわれ、スケジュール・使用資源表66に登録される。
次に、スケジュール・使用資源表66について説明する。図19にその一例を示す。図19において、TV録画アプリケーションA(アプリケーション60)は、タスクaとタスクcよりなる。TV録画のタスクaは、2002年11月1日の12:00から13:00までの番組を予約録画するように指令されているので、開始時刻欄と終了時刻欄に、その旨が登録されている。図示しないが、この他のデータとして、チャンネル番号や番組コードなども登録される。タスクcは、録画した番組を30分遅れでタイムシフトして見るアプリケーションAの機能の一部であり、2002年11月1日の12:30から13:30まで実行するように予約され、登録されている。図示しないが、この他のデータとして、録画された番組のチャンネル番号や番組コード、あるいはHDD内の番組ファイル管理コードなどが登録される。アプリケーションB(暗号通信アプリケーション70)は、ネットワークカメラの映像データの受信機能と表示機能を実現するものであり、タスクbより成る。このタスクbは、2002年11月1日の11:45から以降継続して実行されるように、リモコンにより指示されており、スケジュール・使用資源表66の開始時刻と終了時刻に、その旨が登録されている。
また、スケジュール・使用資源表66には、各タスクa、b、c、それぞれの実行に必要とする使用資源の量、すなわちCPUの処理能力、メモリ量、通信する場合のデータ転送量が、それぞれ、平均使用CPU資源(メガインストラクション/秒:MIPS)、平均使用メモリ資源(メガバイト:MB)、暗号通信の平均データ転送量(メガビット/秒:Mbps)として記憶されている。タスクa、cについては、暗号通信を行なわないので、暗号通信の平均データ転送量は0Mbpsである。暗号通信欄には暗号通信の有無を記載してある。タスクbについては暗号通信欄が「する」となっている。また、必要暗号強度の欄には、暗号通信の際の必要暗号強度を指定している。この例では、タスクbにおいて利用する暗号アルゴリズムは、暗号強度が1位、2位、3位のものの中から選ぶように指定されている。
暗号情報決定部74は、内部に暗号処理使用資源表76を備えている。暗号処理使用資源表76の例を、図20に示す。図20において、暗号処理部80が保有している2種の暗号アルゴリズム(DES−CBC、3DES−CBC)について、それぞれの使用資源の量、すなわち平均使用CPU資源(単位:MIPS/Mbps)、平均使用メモリ資源(MB)、暗号強度順位が記憶されている。平均使用CPU資源の単位は、この例においては、1Mbpsのデータ転送量を暗号化・復号化する際に必要なCPU処理能力をしめす。データ転送量が多いほど、暗号化・復号化の処理能力が比例的に多く必要になる。1Mbpsのデータを転送する場合は、それぞれ100MIPS、300MIPSのCPU処理能力を消費することを示している。
図21は、スケジュール・使用資源表66と暗号処理使用資源表76に基づくCPU使用率の時間推移を示した図である。CPU使用率は、CPUの最大処理能力を1000MIPSとした場合の%で表示している。破線は暗号アルゴリズムとしてDES−CBCを採用した場合のCPU使用率を示しており、一点鎖線は暗号アルゴリズムとして3DES−CBCを採用した場合のCPU使用率を示している。タスクaとタスクcに加えてタスクbを処理する12:30〜13:00の区間で、CPU使用率が最も高くなっている。CPU使用率は、処理量の瞬間的揺らぎや予測できない緊急の処理に対応できるように、余裕を残すようにするのが一般的である。正常な処理を行なうのに支障がない許容総平均CPU使用率を50%とした場合、図21では、3DES−CBCの場合、12:00〜13:00においてCPU使用率が50%を超えるため正常な処理に支障をきたす恐れがあることになる。一方、DES−CBCなら全時間においてCPU使用率が50%以下である。
本実施の形態では、スケジュール・使用資源表66と暗号処理使用資源表76を使用して、許容資源使用量、すなわち許容総平均CPU使用率(または許容CPU処理能力)を超えないように、暗号アルゴリズムをスケジューリングする。
このために、次のようなスケジュール解析処理を行なう。スケジュール部64は、スケジュール・使用資源表66の内容と内部時計(図示しない)を監視する。そして、内部時計の現在時刻より一定時間後(例えば、5分後)のイベントの有無を調べる。図19のスケジュール・使用資源表によれば、現在時刻11:40以前では、5分後のイベントがないので、スケジュール部64は待機状態である。11:40になると、スケジュール部64は5分後にイベントが予定されていることを検知する。するとスケジュール部64は、スケジュール・使用資源表66内に登録された全タスクを調べ、それらの開始時刻、終了時刻によって区切られる各イベント区間(ここでは、区間(11:45〜12:00)、区間(12:00〜12:30)、区間(12:30〜13:00)、区間(13:00〜13:30)、区間(13:30〜未定))ごとに、平均使用CPU資源の合計値を算出する。暗号通信を行なうタスクbでは、暗号強度第3位以上の暗号アルゴリズムから選択することが指定されているので、暗号処理使用資源表76に記載された各暗号アルゴリズムそれぞれを適用した場合の平均使用CPU資源の合計値を算出する。
なお、5分後のイベントの有無を調べる代わりに、何らかのアプリケーションの実行が予約された時点において、上記平均使用CPU資源の合計値を算出するようにしてもよい。
図22は、合計値を算出するためにスケジュール部64が作成するイベント・使用資源表68の例である。図22(1)は、DES−CBCを使用した場合のイベント・使用資源表68である。各イベント時刻毎に、タスク名毎の動作状況(稼動/非稼動)とその使用資源の欄、暗号アルゴリズム名とその使用資源欄、および使用資源合計の欄が設けられる。タスクが複数ある場合は、その数だけの欄が設けられる。各欄には、そのイベント時刻から次の行のイベント時刻までの間に実行すべきタスクや暗号アルゴリズムについての記入が行われる。すなわち、各イベント時刻から次のイベント時刻の間に予約されているタスク名とその使用資源量を記載する。あるタスクがある時刻で終了する場合は、その終了時刻をイベント時刻の欄に記入した行を設け、終了すべきタスク名を記載しないようにすればよい。暗号アルゴリズムを使用する場合は、暗号アルゴリズム名とその使用資源量も記載する。DES−CBCは、図20の例では100MIPS/Mbpsであるが、カメラアプリケーション(アプリケーションB)における映像データの暗号通信の平均データ転送量が、図19の例では1Mbpsであるので、DES−CBCの平均使用CPU資源は100MIPSになる。図22(2)は、3DES−CBCを使用した場合のイベント・使用資源表68である。図22(1)および図22(2)の使用資源合計の欄をCPU処理能力1000MIPSに対して%表示すれば、それぞれ、図21の破線と一点鎖線のCPU使用率(%)の時間推移になる。
スケジュール部64は、作成したイベント・使用資源表68の使用資源合計欄を調べ、最大CPU処理能力1000MIPSの許容総平均CPU使用率50%である許容CPU処理能力500MIPSを常に超えないような全ての暗号アルゴリズムを選択し、選択した暗号アルゴリズム名を暗号情報決定部74に通知する。暗号情報決定部74は、通知された暗号アルゴリズム名と暗号処理使用資源表76とを参照して通知された暗号アルゴリズムの中から最も暗号強度が強いものを選択する。本実施の形態では、DES−CBCのみが暗号情報決定部74に通知されるので、この暗号アルゴリズムが選択される。
つぎに、暗号情報決定部74は、採用したDES−CBCを使用することをスケジュール部64に通知する。スケジュール部64は、通知された暗号アルゴリズムの使用をスケジュール化する。この例では、図22(1)を選択する。以上で、スケジュール解析に基く暗号アルゴリズムの選択とその使用スケジュールが作成できた。
スケジュール部64は、通知された暗号アルゴリズム(ここではDES―CBC)に対応する図22(1)のイベント・使用資源表68を使用して、予約された各アプリケーションの起動・実行・停止を制御する。スケジュール部64は、イベント・使用資源表68(図22(1))を常時参照しており、内部時計が11:45になると、スケジュール部64は、暗号通信アプリケーション70に対してタスクbを起動するよう指示し、暗号処理部80に対してDES−CBCを使用して暗号通信の前処理を行なうように指示する。
暗号処理部80は、暗号通信の前処理として、暗号通信に必要な共有鍵の作成のため、通信相手である図43のネットワークカメラの暗号処理部204との間で、ネゴシエーションを行ない、Diffie−Hellman、IKE、IPsecなどの仕様にしたがって、共有鍵を作成する。暗号処理部80、204の両方で共有鍵の作成が終了すると、通信装置では、暗号処理部80が暗号通信アプリケーション70に暗号通信ができることを通知し、ネットワークカメラでは、暗号処理部204が暗号通信アプリケーション200に暗号通信ができることを通知する。通知を受けた暗号通信アプリケーション200は、カメラの映像データを暗号処理部204に送り込み、暗号処理部204はDES−CBCによりこの映像データを暗号化し、通信処理部206は暗号化された映像データパケットを作成してインターネット回線網を介して通信処理部78にパケットを送る。暗号処理部80は、通信処理部78より受信したデータを受取って暗号の復号化を行ない、映像データを暗号通信アプリケーション70に渡す。暗号通信アプリケーション70は、既に説明したように、映像をディスプレイに表示する。スケジュール部64は、内部時計を参照して現在時刻が12:00になったことを検知すると、イベント・使用資源表68に従い、タスクbを継続しつつ、タスクa(すなわちアプリケーション60)を起動する。12:30になるとさらにタスクcを起動する。13:00になるとタスクaを停止する。13:30になるとタスクcを停止する。すなわち、各イベント時刻になると、そのイベント時刻の行の内容をひとつ前のイベント時刻の行の内容と比較し、前行から新たに追加されたタスクや暗号アルゴリズムを起動し、前行から記載がなくなったタスクや暗号アルゴリズムがあれば、それらを停止する。
以上のように、この実施の形態5の通信装置あるいはアルゴリズム選択方法では、スケジュール部64が、スケジュール・使用資源表66の予約内容と暗号処理使用資源表76のデータを調べることにより、使用CPU資源量が許容CPU処理能力を超えないような暗号アルゴリズムが選択されるようなスケジュールを作成するようにした。従って、暗号通信の実行中に使用CPU資源量が許容CPU処理能力を超えてしまってシステムが破綻したり暗号通信が中断したりする危険性を予め排除できる。
また、本実施の形態によれば、将来の動作を考慮して暗号アルゴリズムの選択など、暗号設定情報を決定することができるため、途中で暗号アルゴリズムを切り替えなくとも、処理資源が枯渇することを防止できる。また、刻々かわる資源の使用状態に応じて暗号アルゴリズムの選択などを制御する動的な資源使用制御にくらべて、手後れになる危険性を低減できる。
各タスクa、b、cの使用資源の量である、平均使用CPU資源、平均使用メモリ資源、平均データ転送量などの数値は、予め通信装置の製造や出荷時にアプリケーション60や、暗号通信アプリケーション70の内部に記憶しておいてもよいし、あるいは各アプリケーションプログラムをインターネット回線網やTVデータ放送を通じて外部からダウンロードする際に、アプリケーション60や、暗号通信アプリケーション70の内部に記憶しておいてもよい。暗号アルゴリズムの平均使用CPU資源・平均使用メモリ資源・暗号強度順位・後述する前処理命令数などは、暗号処理部80にテーブルを設け、このテーブルに暗号・復号情報として記憶しておいてもよい。この場合は、これらの暗号・復号情報を暗号情報決定部74が読み出して暗号処理使用資源表76に書きこむ。あるいは、暗号処理使用資源表76中に記憶しておいてもよい。
あるいは、暗号アルゴリズムの平均使用CPU資源・平均使用メモリ資源・平均データ転送量・後述する前処理命令数などを前回実行時に計測しておき、計測したデータを図2のCPU使用率情報メモリ44のような記憶部に記憶するようにしてもよい。この計測はリソース監視部82において行ない、計測した情報を暗号情報決定部74に通知し、暗号情報決定部74がこのデータを上記記憶部に記憶しておく。そして、予約指示を受けてスケジュール・使用資源表66を作成する際に、暗号情報決定部74はこれらのデータを上記記憶部から読み出してスケジュール・使用資源表66の所定欄に書き込む。暗号アルゴリズムに関するデータは、計測結果を暗号処理使用資源表76に転送してもよい。一般に、CPU処理能力の使用量の計測は、モニタプログラムやカーネルプログラムの一部を利用して行なう。実行タスクのCPU処理能力の使用量をCPU自身が計測できる場合は、その計測結果をCPUが暗号情報決定部74に通知するようにしてもよい。
なお、本実施の形態では、図22(1)と図22(2)に示すように、暗号アルゴリズム毎に別々のイベント・使用資源表68を設けているが、後述する実施の形態7で説明する図25や図26のように、表の共通部分をまとめてひとつの表の形にしてもよい。
図23は、上記説明した処理を行なう通信装置のハードウェア構成の例である。図23において、CPU94、ROM96、RAM98、HDD104、モデム116は、転送手段92であるバスラインに接続されている。このような構成は、標準的なコンピュータシステムの構成である。ROM96には、システム起動用のプログラムや、書き換える必要のないデータが格納されている。HDD104内のエリア106には、システム全体の統括や種々の制御を行なうオペレーションシステム(OS)のような制御プログラム、CPU94をリソース監視部82として機能させるためのリソース監視部プログラム、CPU94を通信処理部78として機能させるための通信処理部プログラムが格納されている。エリア108には、CPU94をスケジュール部64として機能させるためのスケジュール部プログラム、CPU94を暗号情報決定部74として機能させるための暗号情報決定部プログラムが格納されている。エリア110には、CPU94を暗号処理部80として機能させるための暗号処理部プログラム、暗号アルゴリズムのプログラムが格納されている。エリア112には、アプリケーションプログラム、暗号通信アプリケーションプログラムが格納されている。エリア114のファイル部には、録画したテレビ番組のデータが格納される。アンテナ84とチューナ86により受信されたテレビ番組のトランスポートストリームは、エリア112からRAM98にロードされたアプリケーション60に従ってCPU94によりデコードされ、そのデコード結果がエリア114のファイル部に格納(録画)される。また、録画されたデータは、所定のタイムシフト時間後に読み出され、CPU94によってAVデコードの処理が行なわれ、デコードされた音声データと映像データは音声処理88と表示処理90を介して音声出力と映像出力として出力される。リモコン102の操作により指示される予約情報は、リモコンIF(インタフェース)100を介してスケジュール部プログラムが受取り、スケジュール部プログラムはこれをスケジュール・使用資源表66に登録する。その後、CPU94は、制御プログラムに従って、スケジュール部プログラム、暗号情報決定部プログラム、暗号処理部プログラム、暗号アルゴリズムプログラム、アプリケーションプログラム、暗号通信プログラム、リソース監視部プログラム、および通信処理部プログラムをRAM98上に順次ロードし、各プログラムにしたがって上記説明した処理を行なう。
次に、実施の形態5を基本として、その他の実施の形態について説明してゆく。以下、各実施の形態の説明においては、ブロック構成が実施の形態5の場合と同じ部分については繰り返しの説明を省き、異なる部分を中心に説明する。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
(実施の形態6)
図18で説明した実施の形態5の通信装置においては、暗号通信に先立つ前処理、すなわち各種暗号通信にかかわるパラメータのネゴシエーションや共有鍵の交換の処理に無視できない時間がかかる場合には、予約した時間どおりに暗号通信を開始できないという問題が発生する。実施の形態6は、このような課題を解決するためのものである。
本実施の形態では、図20の暗号処理使用資源表76に、図24に示すように、前処理命令数の欄をさらに設け、各暗号アルゴリズム毎に、前処理に必要なCPU処理量を実行命令数Im(単位MI:メガインストラクション)として記載しておく。この数値は、予め通信装置の製造あるいは出荷時に記憶しておいてもよいし、前回に前処理を行なったときにCPUの実行命令数を計測しておき、これを記憶するようにしてもよい。計測する場合は、リソース監視部82において計測を行ない、計測結果を資源情報として暗号処理使用資源表76に記憶する。実施の形態5のイベント・使用資源表68作成時に、暗号通信タスクbの開始イベント以前の時間帯における(許容CPU処理能力−使用資源合計)=CPU処理能力余裕値Ycpu(MIPS)を算出し、Mt(秒)=Im/Ycpuを求めると、前処理に必要な時間が求まる。
なお、共有鍵の処理には、相手機器の処理時間と通信時間も必要である。相手機器の処理時間が無視できる場合は、上記計算値に余裕値αを加算した値を前処理に必要な時間としてもよい。相手機器の処理時間が無視できない場合は、この処理時間も考慮しなければならない。相手機器での処理時間が本装置の処理時間とほぼ同等の場合は、Mt=(Im/Ycpu)×2+β(βは通信時間および余裕時間)とすればよい。また、前回の暗号通信時の処理時間を記憶しておいて、本装置と相手機器の処理時間の合計値に余裕時間を加算したものをMtとしてもよい。本通信装置と同じように、相手機器のCPU処理能力が状況により変動するなどの理由により相手機器の処理時間が分からない場合は、相手機器に処理時間を問い合わせる処理を行った後にMtを決定すればよい。いずれにしても、前処理に必要な時間Mt=Im/Ycpu+δ+β(δは相手機器の処理時間)とすればよい。
Mtが求まると、スケジュール部64は、イベント・使用資源表68のタスクbの開始時刻をMt(秒)だけ早める。このようにすれば、暗号通信アプリケーション70のタスクbは、11:45のMt(秒)前に起動するから、前処理を完了するMt(秒)後、すなわち11:45には暗号通信アプリケーション70の暗号通信が実際に行なえるようになる。具体的には、タスクbの開始イベント時刻よりもMtだけ早い時刻にタスクbの前処理の開始を示すイベントを追加挿入しておき、スケジュール部64が11:45のMt(秒)前に前処理の開始を暗号処理部80に指示するようにし、前処理が完了した11:45にタスクbを起動するようにする。
本実施の形態によれば、暗号通信の前処理を行なうべき時間帯のCPU処理能力余裕値Ycpuが少ない場合には、より早めに前処理を開始でき、暗号通信を予約時間通りに開始することが可能になる。
また、本実施の形態によれば、将来の動作を考慮して前もって共有鍵などの暗号・復号情報を用意できるため、必要なときにすぐに暗号通信を行なうことができる。また、資源の使用レベルが低いときに、共有鍵などの暗号・復号情報を用意しておける。
なお、ある暗号アルゴリズムを途中でいったん別の暗号アルゴリズムに切り替えてから再び元の暗号アルゴリズムを使用する場合に、暗号アルゴリズムを切り替える前に使用していた通信用の鍵を、当該別の暗号アルゴリズムの使用中も保持しておき、再び元の暗号アルゴリズムを使用するときにこの鍵を再利用するようにしてもよい。これにより、再び元の暗号アルゴリズムを使用する際の前処理を省略することができる。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
(実施の形態7)
つぎに、実施の形態7として、ひとつの暗号通信アプリケーションにおいて、許容CPU処理能力Kcpu(MIPS)までの範囲で、暗号強度が最も大きい暗号アルゴリズムを切換選択して使用するようにした実施の形態について説明する。本実施の形態の構成は図18と同様である。以下では、実施の形態5と異なる部分について説明する。
図21または図22を参照すると、CPU処理能力が許容CPU処理能力Kcpu(MIPS)である500MIPSを超えない、すなわちCPU使用率が許容限界である50%を超えない暗号アルゴリズムは、区間(11:45〜12:00)と区間(13:00〜未定)では3DES−CBCとDES−CBCであるが、前者の方が暗号強度の順位が高い。スケジュール部64は、図22(1)および図22(2)のイベント・使用資源表68に基づいて、各イベント区間ごとに、使用資源合計が許容CPU処理能力Kcpu(MIPS)=500MIPSを超えない暗号アルゴリズムを暗号情報決定部74に通知する。暗号情報決定部74は、通知された暗号アルゴリズムが複数ある場合には暗号強度が最も大きいものを選択し、選択した暗号アルゴリズムをスケジュール部64に通知する。イベント・使用資源表68には、イベント時刻毎かつ暗号アルゴリズム毎に、その暗号アルゴリズムが選択されたかどうかを示す選択記入欄(図示せず)が新たに設けられ、スケジュール部64は、暗号情報決定部74から通知された暗号アルゴリズムの選択記入欄に、その暗号アルゴリズムが選択されたことを示す選択コードを記入する。つぎに、スケジュール部64は、実施の形態6の場合と同様に、暗号アルゴリズムを切換えるべきイベント時刻の前の時間帯における(許容CPU処理能力−使用資源合計)=CPU処理能力余裕値Ycpu(MIPS)を算出し、Mt(秒)=Im/Ycpuを求め、このイベント時刻のMt(秒)前に、前処理のイベントを挿入する。このようなイベント・使用資源表68(DES−CBCに対応するものと、3DES−CBCに対応するものの両方)を作成した後、スケジュール部64は、このイベント・使用資源表68を参照しながら、各アプリケーションや、次に使用する暗号アルゴリズムの前処理および暗号処理などの起動・実行・停止の制御を行なう。このとき、スケジュール部64は、イベント・使用資源表68の上記選択記入欄の選択コードを参照して、選択された暗号アルゴリズムの前処理と、暗号化・復号化の処理を、暗号処理部80に行なわせる。
図25は、実施の形態7で用いられるイベント・使用資源表68の一例である。イベント時刻欄には、年月日時刻の内、少なくとも時刻が記載される。タスク/資源欄には、予定タスク名と使用資源量(MIPS)が記載される。使用資源量(MIPS)は平均使用CPU資源の量である。タスク/資源欄は、予約アプリケーションが増えると、必要に応じて増設される。暗号/資源欄には、候補暗号アルゴリズム名と使用資源量(MIPS)が記載される。資源合計欄には、予定タスクと候補暗号アルゴリズムによる使用資源合計(MIPS)が記載される。暗号/資源欄と資源合計欄は、候補暗号アルゴリズムの数だけ設けられる。
使用暗号欄には、使用資源合計が許容CPU処理能力を超えない範囲で、暗号強度が最も高い暗号アルゴリズム名が記載される。この処理は次のように行なえばよい。スケジュール部64が、各イベント区間毎に、使用資源合計が許容CPU処理能力を超えないような候補暗号アルゴリズムを暗号情報決定部74に通知する。暗号情報決定部74は、図20の暗号処理使用資源表76を参照して、通知された候補暗号アルゴリズムの中から暗号強度が最も高いものを選択し、その暗号アルゴリズム名をスケジュール部64に通知する。スケジュール部64は、通知された暗号アルゴリズム名を使用暗号欄に記載する。
以上のように、本実施の形態によれば、使用CPU資源量が許容CPU処理能力を超えないような、かつ暗号強度が最も高い暗号アルゴリズムを、イベント区間毎に選択することができるため、CPUの使用率の変化に応じて、随時最適な暗号アルゴリズム使用することができる。
イベント・使用資源表68は図25の例に限らない。例えば、図26の暗号アルゴリズムの欄のように、暗号アルゴリズム名と資源の量とを別の欄に記載するようにしてもよい。
(実施の形態8)
次に、実施の形態8として、前述した実施の形態7と実施の形態6を組み合わせた実施の形態について説明する。つまり本実施の形態は、実施の形態7において、暗号通信の前処理に無視できない時間がかかる場合に対処するために実施の形態6と同様に前処理を早めに行なうようにしたものである。
図27は、本実施の形態で使用されるイベント・使用資源表68の一例である。つまり、図25に示したイベント・使用資源表68に対して前処理欄と前処理暗号欄が新たに追加されている。前処理欄には、実施の形態7において説明した、前処理にかかる時間Mt(秒)=Im/Ycpuが記載される。前処理暗号欄には、前処理の対象となる暗号アルゴリズム名が記載される。なお、前処理欄は必要がなければ省略してもよい。
つぎに、図25のイベント・使用資源表68から図27のイベント・使用資源表68を作成する手順について説明する。最初に使用する予定の暗号アルゴリズム3DES−CBCについて、11:45の直前の状態に基づいてMt(秒)=Im/Ycpuを計算する。この計算結果がMt=180(秒)であったとする。11:45よりMtだけ前には前処理を開始する必要があるため、11:45の180秒前、すなわち11:42のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にMt1=180を記載し、前処理暗号欄に3DES−CBCの略号3Dを記載する。
12:00には暗号アルゴリズムがDES−CBCに切り替わるので、この直前の状態に基づいてMt(秒)を計算する。この計算結果がMt=120(秒)であったとする。12:00までには前処理を完了する必要があるので、12:00の120秒前、すなわち11:58のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にMt2=120を記載し、前処理暗号欄にDES−CBCの略号Dを記載する。
13:00には暗号アルゴリズムが3DES−CBCに切り替わるので、この直前の状態に基づいてMt(秒)を計算する。この計算結果がMt=225(秒)であったとする。13:00までには前処理を完了する必要があるので、13:00の225秒=3.75分=約4分前(15秒は余裕分である。)、すなわち11:56のイベント時刻欄を有する行を挿入する。そして、この行の前処理欄にMt3=225を記載し、前処理暗号欄に3DES−CBCの略号3Dを記載する。
挿入された行の、タスク/資源、暗号/資源、資源合計の欄にはそれぞれ、その上段の内容をコピーして記載する。
このようにして作成したイベント・使用資源表68を使用して、スケジュール部64は、タスクa〜c、暗号処理の前処理、暗号処理の、起動・制御・停止を行なう。その結果、暗号アルゴリズムの使用前に前処理を完了できるので、予約時間通りに暗号通信アプリケーション(例えばカメラアプリケーション)を開始できる。
本実施の形態の場合、暗号処理部80として、ある暗号アルゴリズムの実行と別の暗号アルゴリズムの前処理とを並行して実行できるものを設けておく。
ところで、前処理を行なうべき時間帯において他のタスクの追加や停止が行われる場合は、CPU処理能力余裕値Ycpu(MIPS)が一定値ではなく変動するから、Mt(秒)を単純にIm/Ycpuにより求めることができない。そこで、このような場合には、前処理を完了しておくべき時刻から時間をさかのぼる方向へCPU処理能力余裕値Ycpu(MIPS)の積分値を求めてゆき、積分値が前処理に必要なCPU処理の実行命令数Im(単位MI:メガインストラクション)になる時間長をMt(秒)として採用すればよい。この場合、イベント・使用資源表68には、新たなイベント時刻欄を有する行が、暗号アルゴリズムの使用開始や切り換えの直前ではなく、いくつか上段の行の直前に挿入されることになる。
なお、上記図27のイベント・使用資源表68では、12:56に次に使用する3DES−CBCのための前処理を行なうようにしたが、12:00に3DES−CBCからDES−CBCに変更した後も3DES−CBCの公開鍵、秘密鍵などを破棄せず3DES−CBCを再度使用できる状態としておき、12:56から設定した前処理を行なわないようにしてもよい。このようにすれば、前処理の再実行によるCPU資源の消費を削減できる。
(実施の形態9)
次に、実施の形態9として、実施の形態8において候補暗号アルゴリズムが3つに増えた場合の例を説明する。図28および図29は、候補暗号アルゴリズムとして、DES−CBC、3DES−CBC、AES(Advanced Encryption Standard)が用意されている場合のイベント・使用資源表68と暗号処理使用資源表76の例である。AESは、平均使用CPU資源量が多くない割に暗号強度が大きく、3つの暗号アルゴリズムの中では暗号強度が1位である。イベント・使用資源表68では、3つの候補暗号アルゴリズムに対応して、それぞれ資源合計が計算される。11:45のイベント時刻を例にとると、許容CPU処理能力500(MIPS)を超えない暗号アルゴリズムは、DES−CBC、3DES−CBC、AESである。スケジュール部64は、この3つを候補として暗号情報決定部74に通知する。また、図19のスケジュール・使用資源表66では、11:45開始のタスクbで使用する暗号アルゴリズムは暗号強度が第3位以上のものとする条件がついている。この情報もスケジュール部64から暗号情報決定部74に通知される。暗号情報決定部74は、図29の暗号処理使用資源表76を参照して、3つの暗号アルゴリズムの中から暗号強度が第3位以上のもので、かつその中で暗号強度順位が最も高いもの(ここではAES)を選択し、スケジュール部64に通知する。そして、スケジュール部64は、使用暗号欄の11:45イベント時刻の欄にAES(略号A)を記入する。
(実施の形態10)
Diffie−Hellman交換やIKEによる共有鍵の交換では、共有鍵の寿命を設定することができるようになっている。ひとつの鍵を長時間使用すると、その間に鍵を盗まれて解読される危険性が増える。このため、新たな鍵、すなわち更新鍵を作成しておき、適切な時間後には更新鍵に切り替えるようにする方式が有効である。このような鍵の寿命を設ける方式では、鍵の寿命が満了になる前に、次に使用する更新鍵の生成を完了しておく必要がある。更新鍵の生成を行なうことをリキー処理と呼ぶ。最初の鍵の生成、リキー処理の両方とも、鍵の生成には暗号化や復号化と同様に大きなCPU処理能力を必要とする場合が多い。したがって、鍵寿命満了時刻よりも充分前の時刻にリキー処理を開始することが望まれる。しかしながら、リキー処理を行なうべき時間帯に大きなCPU処理能力を消費するアプリケーションがあると、CPUの処理負荷が許容CPU処理能力を超えてしまい、更新鍵の準備が間に合わなくなる。
そこで、本実施の形態10においては、鍵を更新するまでの鍵寿命の値と予約スケジュールに基く使用資源合計値の推移とを考慮して、適切なリキー処理開始時刻をイベント・使用資源表68にイベントとして追加する。
まず、暗号処理使用資源表76に鍵寿命時間の欄を設け、各暗号アルゴリズム毎に、設定する予定の鍵寿命時間Jtを記載する。なお、一般的には、全体の危険度を一定とするためには、アルゴリズムの暗号強度が高いほど鍵の寿命を長くすることができる。暗号アルゴリズム使用の開始時刻をCtとし、最初の鍵の使用開始時刻をKt1とすると、最初の鍵の使用開始時刻はKt1=Ctであり、鍵の寿命満了時刻は(Ct+Jt)である。時刻(Ct+Jt)の前の時間帯でのCPU処理能力余裕値をYcpu(MIPS)とし、リキー処理に必要なCPU命令数をIr(単位MI:メガインストラクション)とすると、リキー処理に必要な時間はRt=Ir/Ycpuである。時刻(Ct+Jt−Rt)までにリキー処理を開始すれば、鍵の寿命満了時刻(Ct+Jt)までに更新鍵を準備できる。
なお、CPU処理能力余裕値Ycpu(MIPS)が、リキー処理予定の時間帯において一定値ではなく変動する場合は、実施の形態8における前処理の場合と同様の考え方により、リキー処理を完了しておくべき時刻(Ct+Jt)から時間をさかのぼる方向へCPU処理能力余裕値Ycpu(MIPS)の積分値を求めてゆき、積分値がリキー処理に必要なCPU処理の実行命令数Irになる時間長をRtとして採用すればよい。
つぎに、リキー処理開始時刻(Ct+Jt−Rt)をイベント時刻としたリキー処理イベントの行をイベント・使用資源表68に挿入することによって、リキー処理をスケジュールに記入する。この操作は、暗号通信の前処理で説明したのと同様の操作を、スケジュール部64と暗号情報決定部74の間で行なえばよい。
次の更新鍵の寿命に対しては、鍵の寿命満了時刻が(Ct+2*Jt)となるので、この時刻に対するリキー処理開始時刻を求め、追加イベントを設ければよい。同様の操作を、暗号アルゴリズムの使用終了予定のイベント時刻まで行なう。
以上のように、本実施の形態弐よれば、予定されるCPU処理能力余裕値Ycpu(MIPS)に応じたリキー処理の計画を予め立てられるので、リキー処理時に許容CPU処理能力を超過してシステムが破綻することが無くなる。
なお、Rtは、若干の余裕を持たせるために一定時間分αだけ長めにするのが安全である。
鍵の寿命を管理する場合、一般的には、
(1)時間で管理する手法(例えば、鍵の寿命を、鍵を生成してからの経過時間(X秒)や鍵の使用を開始してからの経過時間(Y秒)により規定する手法)
(2)データ転送量で管理する手法(例えば、鍵の寿命を、処理パケット数(mパケット)や処理バイト数(nバイト)により規定する手法)
などの手法があるが、本実施の形態は、(1)の手法のうち、鍵の使用を開始してからの経過時間により鍵の寿命が規定されている場合に簡単に適用できる。鍵を生成してからの経過時間により鍵の寿命が規定されている場合には、以下のような工夫をすればよい。鍵の生成時刻は、本通信装置と通信相手の機器とで同じ時刻でない場合がある。すなわち、鍵の生成においては、一般的に、相手から公開値を受け取ってから自分の秘密鍵を生成するため、一方の鍵の寿命満了時刻は、公開値を受け取ってから自分の秘密鍵を生成するための時間分だけ遅くなる。この時間関係は、鍵の生成を起動する側の機器と、鍵の生成手順により決まる。このように一方の鍵の生成が他方よりも遅れる場合、早く生成される側の鍵の生成時刻を起点としてJtを鍵の寿命とすれば、時間Jtの間は、両方の鍵が寿命時間内になり、一方の鍵の寿命が寿命満了になることはない。また、本装置と相手機器とが通信により、双方の鍵の生成が完了したことを知ることができる場合は、その時点を鍵の寿命起算の時点とすればよく、双方の鍵の寿命満了時刻は一致する。
なお、上記説明では、本通信装置側の処理時間だけを考慮する場合を例として説明したが、共有鍵の処理には相手機器の処理時間と通信時間も必要である。これらを考慮するためには、前処理での相手機器における鍵の生成処理時間を記憶しておいて、これに本通信装置での上記Rt=Ir/Ycpuに余裕時間を加算したものをRtとすればよい。ただし、相手機器の処理時間が無視できる場合には、Ir/Ycpuに単に余裕値αを加算した値をRtとしてもよい。また、相手機器での処理時間が本通信装置の処理時間とほぼ同等の場合には、Rt=(Ir/Ycpu)×2+β(βは通信時間および余裕時間)とすればよい。本装置の場合と同様に、相手機器でも、他の一般的なアプリケーションにより処理時間が変わる可能性がある場合は、相手機器に処理時間を問い合わせる処理を行った後にRtを決定すればよい。いずれにしても、Rt=Ir/Ycpu+δ+β(δは相手機器での処理時間)とすればよい。
すでに説明したように、リキー処理においては、暗号アルゴリズム使用の開始時刻Ctを起点として、鍵の寿命満了時刻(Ct+Jt*n)までに更新鍵の生成を完了しなければならない。更新鍵の生成を前の鍵の寿命満了までに確実に行なうための余裕を確保するためにリキー処理を少し早めに開始すると、その分、鍵が早めに生成される。この鍵の寿命がJtであると、本来予定されていた次の鍵の寿命満了時刻(Ct+Jt*(n+1))よりも早くこの鍵の寿命が満了するおそれがある。このようなことを避けるには、リキー処理において設定する鍵寿命を、スケジュール上の鍵更新の時間間隔よりも少し長めにすればよい。
(実施の形態11)
つぎに、実施の形態11として、イベント・使用資源表68から予定されるCPU処理能力余裕値Ycpu(MIPS)の推移に応じて、鍵の寿命値を適切に設定する実施の形態について説明する。
スケジュール部64と暗号情報決定部74が、使用する暗号アルゴリズムを選択した段階で、スケジュール部64は、スケジュール・使用資源表66および暗号処理使用資源表76を参照して、あるいはイベント・使用資源表68を参照して、暗号アルゴリズム使用開始時刻Ctの前の時間帯におけるCPU処理能力余裕値Ycpu(MIPS)を調べる。そして、リキー処理に必要な時間Rt=Ir/Ycpuを求め、さらに(Rt+α)を計算し、この値を鍵の寿命として暗号情報決定部74に通知する。なお、αは余裕値である。よって、鍵の寿命満了時刻は(Ct+Rt+α)になる。つぎに、(Ct+Rt+α)の前の時間帯におけるCPU処理能力余裕値を調べ、リキー処理に必要な時間を計算し、次の更新鍵の寿命とする。このような処理を繰り返し、各リキー処理の開始時刻をイベントに追加する。鍵の寿命完了と同時に、リキー処理を開始し、リキー処理完了時に、新たに生成した鍵を即座に使用開始することができる。
このようにすれば、CPU処理能力余裕値Ycpu(MIPS)を有効に使用して、早めにリキー処理が行なえるので、鍵の寿命も短くでき、暗号通信の安全性を高く保てる。
また、CPU処理能力余裕値Ycpu(MIPS)の一部分のみを使用するようにすれば、リキー処理時間は長くかかり、その分だけ鍵の寿命時間を長くする必要があるが、かわりに、CPU処理能力に余裕を残せる。
本実施の形態によれば、上記のように柔軟な処理を計画的に組み立てることができる。
本実施の形態は、鍵の寿命を時間で管理する手法の場合に適用するのが好ましい。
(実施の形態12)
図27を参照して説明した実施の形態8や、図28および図29を参照して説明した実施の形態9では、共有鍵を交換する前処理を、暗号アルゴリズムを使用する直前、および暗号アルゴリズムを切り替える直前に行なった。しかしながら、ひとつの暗号通信アプリケーションにおいて複数の暗号アルゴリズムを切り替えて使用する場合には、暗号通信アプリケーションを開始する前に、必要な複数の共有鍵をまとめて生成するようにしてもよい。この場合、図27を例に取れば、前処理のMt1、Mt2、Mt3を11:45までに順番に実行するようなイベントを挿入すればよい。
このように、早めに鍵を生成する場合は、鍵の寿命は、
(1)使用開始からJ秒後
(2)使用開始からmパケット処理後
(3)使用開始からnバイト処理後
などと規定するのがよい。鍵の寿命を鍵の生成からの経過時間で規定する必要がある場合には、上記(1)の時間に、生成以降実際に鍵を使用するまでの時間を加算したものを寿命時間として設定すればよい。
(実施の形態13)
予めスケジュールで「暗号通信アプリケーションを開始してからa秒後に処理負荷が高くなる」と予測される場合に、その暗号通信アプリケーションの開始前に実行される前処理において、予め高強度・高負荷の暗号アルゴリズムと低強度・低負荷の暗号アルゴリズムの両方の鍵を用意しておき、スケジュールで全体処理負荷が高くなると予測される時点で、暗号アルゴリズムを高強度・高負荷のものから低強度・低負荷のものに切り替える方式を取るようにしてもよい。この場合、暗号アルゴリズムを低強度・低負荷のものに切り替えた後に、高強度・高負荷のアルゴリズムの鍵情報を明示的に削除することで、メモリ資源の浪費の低減を図ることが可能である。
なお、鍵の寿命は通信相手と取り決めるのが一般であり、鍵を削除する場合は、その旨を通信相手に通知する必要があるので、そのための通信処理負荷が発生する。このような処理負荷も、スケジュール・使用資源表66およびイベント・使用資源表68に反映させてもよい。
なお、予め高強度・高負荷の暗号アルゴリズムの鍵の寿命を、全体処理負荷が高くなる時点まで(あるいはその前後まで)としておき、鍵の削除の通知の手順を省略するようにしてもよい。
(実施の形態14)
上記各実施の形態では、使用資源として、CPU処理能力(MIPS)に着目し、許容資源使用量である許容CPU処理能力の範囲でのCPUの有効利用と、システムの破綻の防止を行なうようにした。しかしながら、通信装置の資源としては、この他に、使用メモリサイズ(MB)や内部バスラインの時間占有率(%)などがある。例えば、使用メモリサイズがシステムのRAMサイズ(たとえば、521MB)を超えると、HDDへの待避が頻繁に起こり、一部のアプリケーションが予約通りに実行できなかったり、サービスが一時止まってしまうなどの不具合が発生する。また、内部バスラインの時間占有率(%)が100%を超えても同様の事態が起きる。使用資源、すなわち平均の使用メモリサイズや内部バスラインの平均時間占有率を、最大値に対して例えば50%程度の許容資源使用量に押さえるようにすれば、不具合の発生は実質上回避できる。
使用メモリサイズや内部バスラインの時間占有率(%)の合計値についても、上記したスケジュール・使用資源表66やイベント・使用資源表68を作成し、許容値を超えない暗号アルゴリズムを選択するようにすることができる。
また、CPU処理能力、使用メモリサイズ、バスラインの時間使用率の3つの要素のうちのいずれか1つだけでなく、2つあるいは3つの要素を加味した総合的使用率に基づいて暗号アルゴリズムの選択を行なうようにしてもよい。総合的使用率は、一例として、個々の要素の使用率に所定の重みを掛けた加重平均値で表すことができる。
(実施の形態15)
上記各実施の形態では、リモコン102や外部からアプリケーションの実行を予約する。外部からの予約は、携帯型の情報機器や携帯電話からインターネット回線網を介して行なわれることが想定される。
図18や図23の構成において、スケジュール登録用の専用のアプリケーションをさらに設けておき、そこで予約要求を受け付け、この予約要求をスケジュール部64に通知し、スケジュール部64がこの予約要求をスケジュール・使用資源表66に反映させる方法をとることができる。また、各アプリケーションが、予約要求のうち自アプリケーションに関係したもののみを一旦受付け、そしてスケジュール部64に登録を要求する方法もとれる。後者の方法では、アプリケーション特有の形式で登録することができる。
(実施の形態16)
図30は、上記実施の形態5〜15で説明した通信装置で用いられるアルゴリズム選択方法の基本的な手順を示すフローチャートである。なお、フローチャートの各手順は、基本的には通信装置のCPU94によってプログラムに従って実行される。
まず、通信装置は、ステップS3000の予約登録手順において、アプリケーションの予約を受付け、スケジュール登録する。この登録は、基本的には仮の登録である。ステップS3001の平均使用CPU資源合計値算出手順において、受け付けたアプリケーションが暗号通信を行なうものかどうか判定し、暗号通信を行なうものである場合は、それまでに受け付けている他のアプリケーションも含めて、平均使用CPU資源の合計値を算出する。この処理は、複数用意されている暗号アルゴリズムのそれぞれについて行われる。そして、スケジュールのどの時点でも許容CPU処理能力を超えることがないような暗号アルゴリズムを一次選択する。ステップS3002の暗号アルゴリズム選択手順において、一次選択された暗号アルゴリズムの中から必要暗号強度の条件に合致する暗号アルゴリズムを選択する。ステップS3003のスケジュール登録手順において、選択した暗号アルゴリズムの処理をスケジュールに登録する。
なお、上記ステップS3001において、スケジュールのどのイベント区間でも許容CPU処理能力を超えることがない暗号アルゴリズムを一次選択するのではなく、各イベント区間毎に許容CPU処理能力を超えることがない暗号アルゴリズムを一次選択し、ステップS3002において、一次選択された暗号アルゴリズムの中から、必要暗号強度の条件に合致する暗号アルゴリズムを各イベント区間ごとに選択するようにしてもよい。このようにすれば、CPU処理能力に余裕がある区間においては暗号強度がより高い暗号アルゴリズムを選択できる可能性が高まる。
上記各ステップにおいて、平均使用CPU資源合計値が許容CPU処理能力を越えてしまう場合や、ステップS3002において所定条件に合致する暗号アルゴリズムがない場合には、アプリケーションの予約ができないので、その旨を予約の要求元(典型的にはユーザ)に対して通知(回答、表示)する。
なお、上記のようにアプリケーションの予約ができない状況が発生したときに、予約の要求元に対してスケジュール情報を掲示し、仮登録された、あるいは既に予約登録済の暗号通信アプリケーションの暗号アルゴリズムの変更を要求元が行なうことができるようにして特定の予約を優先させることも可能である。また、仮登録された、あるいは既に予約登録済の暗号通信アプリケーションの暗号アルゴリズムのうち、最も処理負荷の高いもの、あるいは最も暗号強度の高いものから順に、暗号アルゴリズムの再選択(より暗号強度の低いものに選択しなおす)を仮に行ない(平均使用CPU資源合計値の再計算を含む)、その結果、新規暗号通信アプリケーションの登録が可能と判断された場合に、上記暗号アルゴリズムの再選択を実際に行なった上で新規暗号通信アプリケーションの登録を行なうことも可能である。このとき、必要ならば、図19において説明した必要暗号強度の条件を緩くして、暗号強度の低い暗号アルゴリズムを新たに選択対象に追加した上で、暗号アルゴリズムの再選択を行ってもよい。また、暗号アルゴリズムを選択できなかったイベント区間に対して、必要暗号強度の条件を緩くした上で、その結果として選択可能となった暗号アルゴリズムの中からより暗号強度の高いものを選択するようにしてもよい。また、このような登録内容の変更は、自動的に行なえるようにしてもよいし、予約要求元による選択指示に基づいて、上記方法の選択や暗号アルゴリズム自体の選択などを行なえるようにしてもよい。
ただし、上記のように必要暗号強度の条件を緩めずに済む場合もある。すなわち、「必要暗号強度第3位以上」のような条件の下で暗号強度が第1位の暗号アルゴリズムが採用されて登録されていた場合には、この条件を緩めることなく、この暗号アルゴリズムをより暗号強度の低いもの(暗号強度が第2位または第3位のもの)に変更することで、新規暗号通信アプリケーションの暗号通信の予約、登録が可能となる場合もある。
また、暗号アルゴリズムの再選択とは別に、アプリケーションの種類によっては、一般のアプリケーションも含めて、その実行開始時刻をずらすことによって、新規要求アプリケーションの登録を可能とするようにしてもよい。また、暗号通信平均データ転送量を暗号通信アプリケーションによって制御できる場合には、その値を低くすることによって、平均使用CPU資源合計値を低減し、新規要求アプリケーションの登録を可能とするようにしてもよい。また、これらの変更を予約要求元が行なう場合は、認証により、変更する権限を有する者のみが変更を許可されるようにしてもよい。
図31は、図30よりも更に詳しいフローチャートである。通信装置は、ステップS3100において、アプリケーションの予約があった場合、その予約を受け付ける。ステップS3101において、スケジュール・使用資源表66に予約を登録する。これは、仮登録である。ステップS3102において、スケジュール・使用資源表66を元にイベント・使用資源表68にイベントを追加する。ステップS3103において、仮登録された予約が暗号通信アプリケーションの予約かどうか判定する。この判定結果がYESなら、すでに登録されている各種アプリケーションに加えて、用意されている複数種の暗号アルゴリズムのそれぞれを使用した場合の平均使用CPU資源の合計値を、各イベント区間について算出する。ステップS3105において、許容CPU処理能力を超えないような暗号アルゴリズムを候補として一次選択する。ここで選択される暗号アルゴリズムの数は、複数、ひとつ、無しのいずれかとなる。ステップS3106において、候補暗号アルゴリズムが一つ以上あるかどうか判定し、この判定結果がYESなら、ステップS3107において、所定の条件を満たす暗号アルゴリズムを選択する。所定の条件とは図19の必要暗号強度である。条件を満たす暗号アルゴリズムがあれば、ステップS3108においてYESと判定される。ステップS3109において、共有鍵交換などの前処理の開始時刻の算出を、実施の形態6で説明した方法により行なう。ステップS3110において、鍵の寿命満了に備えたリキー処理の開始時刻の算出を、実施の形態10で説明した方法により行なう。ステップS3111において、選択した暗号アルゴリズムの使用時刻、前処理の実行時刻、リキー処理の開始時刻をスケジュールに登録する、すなわちイベント・使用資源表68に挿入・追記する。ステップS3112において、イベント時刻まで待機する。次の予約に対して待機してもよい。イベント時刻が到来すれば、そのイベントを実行してゆく。
ステップS3103の判定結果がNO、すなわち予約されたアプリケーションが暗号通信を伴わないものであれば、ステップS3113において、平均使用CPU資源の合計値を各イベント区間に対して算出する。ステップS3114において、その合計値が許容CPU処理能力未満かどうか判定し、この判定結果がYESであれば、ステップS3101、ステップS3102での登録は有効となる。ステップS3114の判定結果がNOであれば、ステップS3101、ステップS3102で登録したアプリケーションをステップS3115において消去する。さらにステップS3116において、「予約が不可能である。」、「予約を失敗した。」旨の通知を予約要求元に対して行なう。ステップS3106、ステップS3108の判定結果がNOの場合、使用可能な暗号アルゴリズムが見つからなかったので予約の登録は失敗し、ステップS3115、ステップS3116の処理を行なう。
図32は、許容CPU処理能力を超えてしまうためにそのままでは新たな予約を登録できない場合に、既存のアプリケーションのアルゴリズムを変更することによりCPU処理能力の余裕を生み出し、予約要求に応えるようにした処理方法の手順を示すフローチャートである。図31のステップS3106、ステップS3108、ステップS3114の判定結果がNO、すなわち暗号アルゴリズムが選択できなかった場合には、ステップS3201において、すでにスケジュールに登録済みの暗号通信アプリケーションのうち、最も負荷が高い暗号アルゴリズムを使用予定の暗号通信アプリケーションを検索する。ステップS3202において、その暗号アルゴリズムを負荷がより低いものに変更した場合の、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて使用資源合計を算出し、ステップS3203において、この算出結果が許容CPU処理能力未満かどうか判定する。この判定結果がYESなら、暗号アルゴリズムの変更を確定し、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて、ステップS3109以降で、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップS3203の判定結果がNO、すなわち許容CPU処理能力がまだ不足であれば、ステップS3205において、暗号アルゴリズムの変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がYESならステップS3201に戻り、そのアプリケーションの暗号アルゴリズムの変更を試みる。ステップS3205の判定結果がNOなら、予約要求に対応することがまったく不可能であるので、ステップS3115に戻る。
図33は、許容CPU処理能力を超えてしまうためにそのままでは新たな予約を登録できない場合に、予約要求元(典型的にはユーザ)に予約の変更を促すように表示を行ない、予約要求元の判断により暗号アルゴリズムの再選択を行なうアルゴリズム選択方法の手順を示すフローチャートである。図31のステップS3106、ステップS3108、ステップS3114の判定結果がNO、すなわちアルゴリズムが選択できなかった場合には、ステップS3300において、予約要求元に再選択を促す表示を行なう。予約要求元はその表示を見て、ステップS3301において、すでにスケジュールに登録済みの暗号通信アプリケーションのうち、最も負荷が高い暗号アルゴリズムを使用予定の暗号通信アプリケーションを検索し、選択する。通信装置は、その選択に応答して、ステップS3302において、その暗号アルゴリズムを負荷がより低いものに変更した場合の、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて使用資源合計を算出し、ステップS3303において、この算出結果が許容CPU処理能力未満かどうか判定する。この判定結果がYESなら、暗号アルゴリズムの変更を確定し、変更した暗号アルゴリズム、予約要求暗号通信アプリケーション、およびそこで使用する暗号アルゴリズムについて、ステップS3109以降で、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップS3303の判定結果がNO、すなわち許容CPU処理能力がまだ不足であれば、ステップS3305において、暗号アルゴリズムの変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がYESならステップS3300において、予約要求元に再選択を促す表示を行ない、ステップS3301以降、暗号アルゴリズム変更を試みる。ステップS3305の判定結果がNOなら、予約要求に対応することがまったく不可能であるので、ステップS3115に戻る。
なお、上記のような暗号アルゴリズムの再選択では、前述したように、必要暗号強度の条件を緩める場合や、必要暗号強度の条件を緩めずに済む場合がある。
図33のフローチャートにおいて、ステップS3301では、ユーザである予約要求元に、暗号アルゴリズムを負荷がより低いものに変更する暗号通信アプリケーションを指定させ、ステップS3302において、指定された暗号アルゴリズムを負荷がより低いものに変更した場合の使用資源合計を算出するようにしてもよい。この場合、ステップS3301において、ユーザである予約要求元に、暗号アルゴリズムを変更可能な暗号通信アプリケーションがどれであるかを予約要求元が識別できるような情報、あるいは暗号アルゴリズムを変更可能な暗号通信アプリケーションの中から所望の暗号通信アプリケーションを予約要求元が選択できるような情報を提示するとともに、現在予約登録されている暗号アルゴリズムと、選択・変更可能な暗号アルゴリズム(すなわち変更対象候補となる暗号アルゴリズム)とを提示し、予約要求元に実際に暗号アルゴリズムの変更を実施するか否かを判定させ、変更する内容を決めさせるようにしてもよい。予約要求元に対して、さらに、どのような暗号アルゴリズムを適用可能かを示す情報、あるいはそれらの暗号アルゴリズムの暗号強度やその順位などの情報を表示・提供してもよい。これにより、予約要求元は、再選択するか否かの判断だけではなく、その内容までも考慮したうえでの判断を行なうことができるようになる。
(実施の形態17)
これまでに、暗号通信アプリケーション、前処理、リキー処理などを予約登録や追加登録する場合について説明した。スケジュール部64がイベントを実行している最中に新たな追加の予約登録の要求が発生した場合であっても、上記各実施の形態において説明した許容資源量の余裕の範囲であればイベントの追加が可能である。スケジュール部64は、追加予約登録要求を受けると、この予約をスケジュール・使用資源表66に仮登録し、作成済みのイベント・使用資源表68に追加アプリケーションに関するタスク欄を設け、さらにその開始希望時刻に対応するイベント行と終了希望時刻に対応するイベント行を挿入した、仮のイベント・使用資源表を別途作成する。そして、挿入した開始希望時刻イベント行と終了希望時刻イベント行に、各々の上段の各タスクと暗号アルゴリズムの記載内容をそれぞれコピーする。そしてさらに、開始希望時刻イベント行から終了希望時刻イベント行の直前のイベント行までの各イベント行に、追加使用希望する使用資源量を追記する。それから、スケジュール部64と暗号情報決定部74は、使用資源量の合計の算定や、その合計と許容資源量との比較を行ない、その合計が許容資源量未満であれば、更に必要に応じて暗号アルゴリズムの選択などの作業を行なう。最終的に予約追加可能であると判定された場合には、上記仮のイベント・使用資源表を正式なイベント・使用資源表68として採用することにより、追加予約希望のアプリケーションをイベント・使用資源表に追加することが可能になる。このような予約追加の判断にかかわる処理は、処理量が多くない。よって、この処理に必要な使用資源は少なく、システムが破綻する可能性は実質上無い。また、この処理に必要な時間も極めて短時間であるので、殆ど即座に対応することが可能である。なお、暗号アルゴリズムを使用する場合は、前処理の所要時間以上早めに予約要求が行われるべきである。そうでなければ、暗号通信の開始が遅れてしまうからである。
反対に、登録済みのあるアプリケーションの予約を取り消す場合には、該当するイベント時刻における、そのアプリケーションを構成するタスク名と、暗号通信の場合は更に、関連する暗号アルゴリズム名と使用資源を、記載欄から削除すればよい。この処理も極めて短時間に行なえるが、スケジュール部64がイベント・使用資源表68を参照して作業している時間帯、すなわちイベント時刻の前後の時間帯を避けて行なうようにする方がよい。暗号アルゴリズムを使用するアプリケーションの予約を取り消す場合には、関連する前処理やリキー処理のイベントについても一緒に削除する。このとき、既に予約登録済みの他のアプリケーションの暗号アルゴリズムを予約要求元に提示することによって予約要求元による暗号アルゴリズムの変更を可能としたり、最も負荷の低いもの、あるいは最も暗号強度の低いものから暗号アルゴリズムの再選択(強度を向上させる)を行なった場合の平均使用CPU資源合計値を算出し、この合計値が許容CPU処理能力を超えなかった場合に暗号アルゴリズムの変更を実施したりすることも可能とする。また、アルゴリズムの再選択とは別に、アプリケーションの種類によっては、許容CPU処理能力を超えない範囲でその実行開始時刻をずらしたり、暗号通信平均データ転送量をアプリケーションによって制御できる場合はその値を高くしたりすることによって、実行完了時刻を早めることも可能である。また、これらの変更を予約要求元が行なう場合は、認証により、変更する権限を有する者のみが変更を許可されるようにしてもよい。
図34は、いずれかのアプリケーションの予約が取り消されたときに、その結果として生まれたCPUの余力を暗号アルゴリズムの暗号強度の強化に振り向ける場合のアルゴリズム選択方法の手順を示すフローチャートである。予約取り消し指示を受けると、通信装置は、ステップS3401において、最も負荷が低い暗号アルゴリズムを使用する予定の暗号通信アプリケーションを検索する。ステップS3402において、その暗号アルゴリズムを暗号強度のより高いものに変更した場合の使用資源合計を算出し、ステップS3403において、その合計が許容CPU処理能力未満かどうか判定する。この判定結果がNOなら、許容CPU処理能力が不足であるので暗号強度の強化はできず、ステップS3112に進む。ステップS3403の判定結果がYESなら、ステップS3404において、図31のステップS3109、ステップS3110、ステップS3111と同様に、暗号アルゴリズムの変更に対応して、前処理、リキー処理なども含めたスケジュール変更を行なう。ステップS3405において、変更の余地のあるアプリケーションが他にまだあるかどうか判定し、この判定結果がYESならステップS3401に戻り、暗号アルゴリズムの暗号強化を試みる。ステップS3405の判定結果がNOなら、ステップS3112に進む。
(実施の形態の変形および補足)
使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合について補足すると、予約済み暗号通信アプリケーションおよび予約要求暗号通信アプリケーションに対して、必要なら前記一定条件(例えば暗号強度が第3位以上等)にかかわらず、暗号アルゴリズムの再選択のための計算を行ない、登録可能なら、再選択を実施して予約登録を行なうようにすることを行ってもよい。これは、予約済みの暗号通信アプリケーション用の暗号アルゴリズムが、前記一定条件を満たす暗号強度の中で強度が上位のものを採用している場合、一定条件はそのままでも、その条件下で、より暗号強度が低位のものに変更する操作を含む。また、このような変更の余地がない場合は、前記一定条件を緩和することを含む。また、前記使用資源合計値が許容資源使用量を越える場合、および所定条件に合致する暗号アルゴリズムがない場合に、他のアプリケーションの実行時間の変更、暗号通信平均データ転送量を低減する変更、もしくはその他の変更を行ない、必要なら前記一定条件にかかわらず、この条件を緩めるなどにより再選択を実施して予約登録を行なうことを可能にしてもよい。上記その他の変更としては、他のアプリケーションの性能を低くしてCPU処理能力の消費量を減らすことが考えられる。このような変更が可能な場合には、このような変更を選択して、暗号アルゴリズムの処理にCPU処理能力を振り向けるようにしてもよい。
上記説明において、許容CPU処理能力を50%とした。また、平均使用CPU資源を用いた。CPUは、アプリケーションの処理以外にOSの処理やカーネルの処理などの基本的処理も並行して行なっているからである。また、アプリケーションの処理において、常に一定のCPU資源を使用するとは限らない。通信においてパケットが集中して到着する場合や、テレビ放送の送信においてデータレートが絵柄のよって変動する場合などもあり、これらの変動を吸収する余裕が必要である。このために、平均使用CPU資源を用い、許容CPU処理能力を100%より小さい値としている。
スケジュール・使用資源表66、イベント・使用資源表68、暗号処理使用資源表76の形式や、表内の各数値は、上記例に限定されない。上記例とは異なった形式であっても、必要な情報が表現でき、資源の計算ができるものであれば、本発明に使用できる。イベント時刻は、分より細かい秒、あるいは秒以下の分解能を持たせてもよい。
図18の構成では、暗号情報決定部74と暗号処理部80の間で暗号・復号情報を授受するようにしたが、暗号情報決定部74が、暗号通信アプリケーション70、72との間でその暗号アプリケーションに対応した暗号・復号情報を授受し、暗号通信アプリケーション70、72が、暗号アプリケーション自身に対応した暗号・復号情報を暗号処理部80との間で授受するようにしてもよい。
図18の構成において、スケジュール部64と暗号情報決定部74とがひとつのブロックで成り、このブロックが、スケジュール・使用資源表66、暗号処理使用資源表76、およびイベント・使用資源表68の3つのテーブルを取り扱うようにしてもよい。
また、図18の構成において、暗号情報決定部74と暗号処理部80がひとつのブロックで成り、このブロックが、暗号処理使用資源表76や暗号・復号情報を扱い、スケジュール部64、暗号通信アプリケーション70、72との間で、関係する情報をやり取りするようにしてもよい。
本発明の通信装置が相手の装置と暗号通信を行なう場合、両者が共に使用可能な暗号アルゴリズムを選択対象とするのが好ましい。本通信装置が選択した暗号アルゴリズムが、相手装置で対応できない場合は、暗号通信ができなくなるのは言うまでもない。したがって、上記予約の段階で、相手装置との間で、使用可能な暗号アルゴリズムを共有化するネゴシエーションを行なうことが好ましい。
通信におけるパケット送信時の揺らぎや、受信におけるパケットの順序の乱れや受信の遅れがあると、使用中の鍵から次の更新鍵に更新される時刻は、鍵の満了時刻の前後に揺らぐ可能性がある。特に受信側でその可能性が大きい。揺らぎ時間が累積してゆき、更新した鍵の使用開始時刻が、スケジュール時に予想した時刻よりも大幅にずれることが懸念される場合は、その分リキー処理開始時刻をずらしてもよい。送信側のネットワークカメラが、鍵の更新を、寿命満了時間に基づき行なう限りは、揺らぎ時間の累積は起こらない。
上記暗号アルゴリズムが認証アルゴリズムあるいは圧縮アルゴリズムであっても、本発明が適用できる。よって、上記の各暗号アルゴリズムは、認証アルゴリズムおよび圧縮アルゴリズムを含むものとする。
なお、本発明のアルゴリズム選択方法の各手順をコンピュータに実行させるためのプログラムを記録した記録媒体としては、プログラムを記録したROM、RAM、フレキシブルディスク、CD−ROM、DVD、メモリカード、ハードディスクなど、コンピュータ読み取り可能な任意の記録媒体が利用できる。
なお、暗号復号情報として、暗号アルゴリズムに加え、暗号鍵等、暗復号処理に必要な情報も含めて通知しても構わない。また、暗号アルゴリズムや暗号鍵を特定する識別子を通知しても構わない。
(実施の形態18)
以上の実施の形態1〜17では、通信装置が自身のCPU使用率(より一般的には使用資源合計値)に基づいて最適な暗号アルゴリズムを選択する例について説明した。ところが、暗号アルゴリズムの選択にあたって通信相手(例えば、ネットワークカメラや、通信機能を有する家電機器)のCPU使用率は考慮されないため、通信相手のCPUリソースに余裕があまりないときに負荷の高い暗号アルゴリズムを選択してしまうと、通信相手における暗号化パケットの復号化処理が遅延してしまう。そこで、実施の形態18として、このような問題を回避可能な通信装置について説明する。
図35に、本実施の形態の通信装置を用いた通信システムの構成を示す。図35に示すように、通信装置120は、ネットワークを介して1以上の通信相手(図35の例では通信相手122、124、126)と通信可能である。
まず、本実施の形態の前提条件を以下に述べる。
<暗号通信に関する前提条件>
・通信装置120は、パケットを暗号化して、1以上の通信相手と暗号通信を行なう。
・暗号化に利用可能な暗号アルゴリズムは複数存在し、通信装置120と通信相手の双方がサポートしている暗号アルゴリズムであれば、任意の暗号アルゴリズムを使用することができる。
・暗号鍵は、少なくとも暗号通信の開始までに、通信装置120と通信相手とで共有される。
・暗号化されたパケットには、少なくともこのパケットの暗号化の際に適用された暗号アルゴリズムと暗号鍵の組を識別するための識別子が含まれる。
・暗号アルゴリズムの折衝方法や暗号鍵を共有するための仕組みについては特に不問である。
<通信相手に関する前提条件>
・通信相手は、パケットを本通信装置に送信するときに、実施の形態1〜15の通信装置のように、自身のCPU使用率に応じて、CPU使用率が許容値を超えないような暗号アルゴリズムを選択し、この暗号アルゴリズムに従ってパケットを暗号化する。
・通信相手は、暗号化されたパケットを通信装置120から受信したときに、このパケットに適用されている暗号アルゴリズムに従ってこのパケットを復号化する。
図36は、通信装置120の構成を示す機能ブロック図である。図36において、通信装置120は、暗号通信アプリケーション128、暗号情報決定部130、暗号処理部136および通信処理部138を備えている。暗号情報決定部130は、暗号処理使用資源表132と受信履歴管理表134を保持している。
図37は、暗号処理使用資源表132の一例である。図37において、「計算量」は、暗号処理を行った場合の負荷を示しており、その値としては、ある通信相手での測定結果を用いる。なお、通信相手での測定結果の替わりに、通信装置120での測定結果や、暗号アルゴリズムに基づいて算出される理論値を用いてもよい。また、図37において、「計算量指標」は、計算量の順位を示しており、計算量が小さい順に1、2、3、・・・という値が設定される。また、「暗号強度」は、暗号の強さの順位を示している。
図38は、受信履歴管理表134の一例である。図38において、「Last」は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを示している。また、「度数」は、一定時間(もしくは一定個数)の受信パケットに適用されていた暗号アルゴリズムの度数を示している。図38において、度数が「*」であるものは、通信相手とネゴシエーションできていない暗号アルゴリズムを示している。
図39は、通信相手122の構成を示す機能ブロック図である。図39において、通信相手122(通信相手122)は、暗号通信アプリケーション140、リソース監視部142、通信処理部144、暗号処理部146および暗号情報決定部148を備えている。暗号情報決定部148は、暗号処理使用資源表150を保持している。なお、リソース監視部142、通信処理部144および暗号処理部146の機能は、図1に示したものと同様である。また、CPU使用率情報メモリ150および暗号処理使用資源表152についても、図2に示したものと同様である。なお、通信相手124、126の構成および動作については通信相手122と同様のため、通信相手124、126の説明は省略する。
以下、通信装置120の動作を説明する。
まず、パケット受信時の通信装置120の動作について説明する。通信処理部138は、ネットワークを介して通信相手から暗号化パケットを受信し、受信した暗号化パケットを暗号処理部136に渡す。暗号処理部136は、この暗号化パケットを解析し、この暗号化パケットに適用されている暗号アルゴリズムと暗号鍵の組を識別するための識別子(以下、第1識別子とする)を抽出し、この第1識別子と、この暗号化パケットの送信元の通信相手を識別するための識別子(以下、第2識別子とする)とを暗号情報決定部130に渡す。暗号情報決定部130は、暗号処理部136から受け取った第1識別子に基づいて暗号アルゴリズムと暗号鍵の組を特定し、これらを暗号処理部136に渡す。また、暗号情報決定部130は、特定した暗号アルゴリズムと暗号鍵の組、および暗号処理部136から受け取った第2識別子に基づいて、受信履歴管理表134を更新する。暗号処理部136は、暗号情報決定部130から受け取った暗号アルゴリズムと暗号鍵の組を用いて暗号化パケットを復号し、こうして平文となったパケットを暗号通信アプリケーション128に渡す。
次に、パケット送信時の通信装置120の動作について説明する。暗号通信アプリケーション128は、通信相手に送信すべき平文のパケットを生成し、これを暗号処理部136に渡す。暗号処理部136は、暗号通信アプリケーション128から受け取ったパケットから第2識別子を抽出し、これを暗号情報決定部130に渡す。暗号情報決定部130は、暗号処理部136から受け取った第2識別子に基づいて、暗号処理使用資源表132および受信履歴管理表134を参照して暗号アルゴリズムを選択する。なお、この暗号アルゴリズム選択処理の詳細は後述する。暗号情報決定部130は、選択した暗号アルゴリズムを暗号処理部136に渡す。暗号処理部136は、暗号情報決定部130から受け取った暗号アルゴリズムにしたがってパケットを暗号化し、この暗号化パケットを通信処理部138に渡す。通信処理部138は、暗号処理部136から受け取ったパケットをネットワークを介して通信相手に送信する。
以下、パケット送信時における暗号情報決定部130の暗号アルゴリズム選択処理の詳細を説明する。前提条件として、暗号情報決定部130は、通信相手との間でネゴシエーションされた1以上の暗号アルゴリズム(図38で「*」が付いていない暗号アルゴリズム)から1つの暗号アルゴリズムを選択する。また、暗号情報決定部130は、通信相手毎に異なる暗号アルゴリズムを選択することができる。
なお、パケット送信時における暗号情報決定部130の暗号アルゴリズム選択方法には複数のバリエーションが考えられる。以下では、6つの典型的なバリエーションについて説明する。
(1)パケット送信先の通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを選択する。
通信相手は、パケット送信時のCPU使用率に応じた暗号アルゴリズムを選択し、この暗号アルゴリズムにしたがってパケットを暗号化して、この暗号化パケットを通信装置120に送信する。したがって、通信相手から受信したパケットに適用されていた暗号アルゴリズムは、そのパケットの送信時の通信相手のCPU使用率を反映している。よって、本方法では、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムが負荷の高いものであった場合には、現在、その通信相手のCPUは余力があると予想されるため、暗号情報決定部130は、通信相手が送信時に適用したのと同じ、負荷の高い暗号アルゴリズムを選択してパケットを暗号化する。一方、通信相手から受信したパケットに適用されていた暗号アルゴリズムが負荷の低いものであった場合には、現在、その通信相手のCPUは余力がないと予想されるため、暗号情報決定部130は、通信相手が送信時に適用したのと同じ、負荷の低い暗号アルゴリズムを選択してパケットを暗号化する。例えば、図38の受信履歴管理表134を保持している状態で通信相手Aにパケットを送信する場合には、暗号情報決定部130は、通信相手Aの「last」の欄に基づいて、暗号アルゴリズム3DES−CBCを選択する。同様に、通信相手Cにパケットを送信する場合には、暗号情報決定部130は、通信相手Cの「last」の欄に基づいて、暗号アルゴリズムAES−CBCを選択する。
この方法を採用する場合には、暗号情報決定部130は、暗号化されたパケットを受信するたびに、図38に示す受信履歴管理表134の「last」の欄を更新する必要がある。なお、この方法では、受信履歴管理表134の「度数」の欄は不要である。
(2)パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。
通信相手のCPU使用率は常に一定というわけではないため、上記(1)の方法のように、たった一つの受信パケットに基づいて暗号アルゴリズムを選択すると、その選択結果が適切でない場合がある。よって、本方法では、暗号情報決定部130は、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。例えば、図38の受信履歴管理表134を保持している状態で通信相手Aにパケットを送信する場合には、暗号情報決定部130は、通信相手Aの「度数」の欄を参照して、過去に受信した20のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高い暗号アルゴリズムDES−CBCを選択する。
この方法を採用する場合には、暗号情報決定部130は、暗号化されたパケットを受信するたびに、図38に示す受信履歴管理表134の「度数」の欄を更新する必要がある。例えば、過去に受信した20パケットを考慮して暗号アルゴリズムを選択する場合には、受信履歴管理表134の「度数」欄に20パケット分の履歴を常に保持しておく。なお、この方法では、受信履歴管理表134の「last」の欄は不要である。
(3)パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。
上記(2)の方法で考慮した、過去に受信した一定数のパケットの中には、かなり前に受信したパケットが含まれる場合もあり、そのようなパケットは通信相手の現在のCPU使用率を推定するための材料としては適切ではない。よって、本方法では、暗号情報決定部130は、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高いものを選択する。例えば、図38の受信履歴管理表134を保持している状態で通信相手Aにパケットを送信する場合には、暗号情報決定部130は、通信相手Aの「度数」の欄を参照して、過去に受信した20のパケットに適用されていた暗号アルゴリズムのうち、最も頻度の高い暗号アルゴリズムDES−CBCを選択する。
この方法を採用する場合には、暗号情報決定部130は、暗号化されたパケットを受信するたびに、図38に示す受信履歴管理表134の「度数」の欄を更新する必要がある。例えば、過去5分間に受信したパケットを考慮して暗号アルゴリズムを選択する場合には、受信履歴管理表134の「度数」欄に1分間分の履歴を常に保持しておく。なお、この方法では、受信履歴管理表134の「last」の欄は不要である。
(4)計算量が、パケット送信先の通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムの計算量以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
計算量が多い暗号アルゴリズムが必ずしも暗号強度が高いとは限らない。例えば、図37に示すように、AES−CBCは、3DES−CBCよりも計算量は少ないが、暗号強度は高い。したがって、もし暗号アルゴリズムとしてAES−CBCと3DES−CBCのどちらも利用可能な場合には、AES−CBCを用いる方が有効である。
また、一般に、受信用にネゴシエーションされたアルゴリズムと、送信用にネゴシエーションされたアルゴリズムは必ずしも一致せず、例えば通信相手から最後に受信したパケットに適用された暗号アルゴリズムを選択しようとしても、この暗号アルゴリズムが送信用にネゴシエーションされたものではない場合もあり得る。
よって、本方法では、暗号情報決定部130は、暗号処理使用資源表132を参照して、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムと比べて計算量が等しいかまたは少ない暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。例えば、図38の受信履歴管理表134を保持している状態で通信相手Bにパケットを送信する場合には、暗号情報決定部130は、計算量が、通信相手Bの「last」の欄に記載されている暗号アルゴリズム3DES−CBCの計算量以下の暗号アルゴリズム(すなわち図37の例では3DES−CBCとAES−CBC。なお、DES−CBCについては図38に示すように通信相手Bとの間でネゴシエーションされていないため除外される。)の中から、最も暗号強度の高い暗号アルゴリズムAES−CBCを選択する。
(5)計算量が、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムの計算量の統計値以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
なお、「統計値」としては、それらの暗号アルゴリズムの計算量のうちの最小値を採用してもよいし、それらの暗号アルゴリズムの計算量のうちの最も頻度の多い計算量を採用してもよいし、それらの暗号アルゴリズムの計算量の平均値を採用してもよいし、その他の統計値を採用してもよい。
例えば、パケット送信先の通信相手から過去に受信した一定数のパケットに適用されていた暗号アルゴリズムの計算量の平均値を「統計値」として採用しており、図38の受信履歴管理表134を保持している状態で通信相手Aにパケットを送信する場合には、通信相手Aの「度数」の欄に基づいて「統計値」は(100×17+300×3)/20=130と計算されるので、暗号情報決定部130は、計算量が130以下の暗号アルゴリズムDES−CBCを選択する。
(6)計算量が、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値以下であるような暗号アルゴリズムの中から、最も暗号強度の高いものを選択する。
例えば、パケット送信先の通信相手から過去一定期間に受信したパケットに適用されていた暗号アルゴリズムの計算量のうちの最も頻度の多い計算量を「統計値」として採用しており、図38の受信履歴管理表134を保持している状態で通信相手Bにパケットを送信する場合には、通信相手Bの「度数」の欄に基づいて「統計値」は3DES−CBCの計算量である300となるので、暗号情報決定部130は、計算量が300以下の暗号アルゴリズムの中で、最も暗号強度の高い暗号アルゴリズムAES−CBCを選択する。
なお、上記(4)〜(6)の方法において、「計算量」の替わりに図37に示す「計算量指標」を用いて暗号アルゴリズムを選択してもよい。
なお、上記の各方法は、過去に受信したパケットに関する情報が受信履歴管理表134に保持されていることを前提としている。しかしながら、ある通信相手に対して初めてパケットを送信する場合や、パケット送信先から長期間パケットを受信していない場合には、受信履歴管理表134に十分な情報が保持されておらず、上記の各方法で暗号アルゴリズムを選択することができない。そこで、このような場合には、一例として、暗号情報決定部130は、予め指定した暗号アルゴリズムを選択するようにしてもよい。また、別の例として、暗号情報決定部130は、まずパケット送信先に、その送信先からの応答が得られるようなパケット、例えばICMP(Internet Control Message Protocol)の「Echo request」を送信し、これに対する応答として送信先から返ってきたパケットに適用されていた暗号アルゴリズムに基づいて、暗号アルゴリズムを選択するようにしてもよい。
図40は、本通信システムの処理の流れを示すフローチャートである。なお、図40において、図16と同様のステップには同一の参照符号を付し、説明を省略する。
図40のフローチャートから分かるように、本実施の形態における通信相手122の動作は、図16に示す通信装置24の動作とほぼ等しい。異なる点は、本実施の形態では、ステップS1700の詳細を示す図17のステップS1702で、集合Fの中で、CPU使用率が許容値以下となるような暗号アルゴリズムの集合Dを求める点のみである。したがって、以下では、通信相手122の動作の説明は省略し、通信装置120側の動作についてのみ説明する。
暗号情報決定部130は、通信相手122から暗号化されたパケットを受信したかどうかを判定し(S1622)、パケットを受信した場合は、このパケットに適用されていた暗号アルゴリズムに基づいて受信履歴管理表134を更新する(S4001)。
一方、通信相手122に送信すべきパケットが存在する場合(S1624でYES)には、暗号情報決定部130は、上述した(1)〜(6)のような方法を用いて集合Fから暗号アルゴリズムをひとつ選択する(S4002)。そして、暗号処理部136は、暗号情報決定部130によって選択された暗号アルゴリズムを用いてパケットを暗号化する(S4003)。
なお、本実施の形態では暗号化プロトコルは不問である。例えば、IPsec(Security Architecture for the Internet Protocol)やSSL(Secure Sockets Layer)等のプロトコルを用いることができる。また、暗号アルゴリズムの種別も不問である。もちろん、送信するパケットの内容も不問である。
本実施の形態では、どの暗号アルゴリズムを選択可能かを通信装置120と通信相手122との間で予め決定しておく必要がある。そのための方法の一例として、管理者が、選択可能な暗号アルゴリズムの種類を通信装置120と通信相手122の双方に予め登録しておいてもよい。また、別の例として、図40のステップS1601およびステップS1621のように、暗号通信に先立って通信装置120と通信相手122との間でネゴシエーションのための通信を行ってもよい。このようなネゴシエーションのための通信は、例えばIKEにも含まれている。
以上のように、実施の形態18によれば、通信装置120は、通信相手122がパケット送信時に適用した暗号アルゴリズムに基づいて通信相手122のCPUの余力を考慮し、通信相手122のCPUの余力に応じた負荷の暗号アルゴリズムを選択することができる。よって、通信相手122は、通信装置120から送信されたパケットの復号処理を無理なくこなすことができる。また、通信装置120は、通信相手122から受信したパケットに基づいて暗号アルゴリズムを選択するため、暗号アルゴリズムを選択するための判断材料(例えば、現在のCPU使用率などの情報)を通信相手122から通信装置120に別途送信する手間(図16のS1603のような処理)は不要である。
(実施の形態19)
実施の形態18における通信相手122のように、自分の都合に合わせて暗号アルゴリズムを選択する機能を側の装置を「主」、同じく実施の形態18における通信装置120のように、相手の都合に合わせて暗号アルゴリズムを選択する側の装置を「従」とすると、通信相手122の機能と通信装置120の機能の両方を備えた通信装置は「主」と「従」の両方になり得る。以下、実施の形態19として、そのような通信装置について説明する。
図41は、実施の形態19の通信装置の構成を示す機能ブロック図である。図41において、通信装置154は、リソース監視部156、暗号通信アプリケーション158、暗号情報決定部160、暗号処理部168および通信処理部170を備える。暗号情報決定部160は、CPU使用率情報メモリ162、暗号処理使用資源表164および受信履歴管理表166を保持している。なお、図41の構成および動作は、暗号情報決定部160の動作を除いて、図36または図39に示したものと同様であるため、ここでは説明を省略する。暗号情報決定部160の動作については後述する。
ところで、2台の通信装置間で通信するときに、この2台の通信装置がいずれも「主」、あるいはいずれも「従」として機能する場合には、実施の形態18のような望ましい効果は得られない。なぜなら、2台の通信装置がいずれも「主」として機能する場合には、一方の通信装置のCPU使用率が高い場合にも関わらず、他方の通信装置は負荷の高い暗号アルゴリズムを用いてパケットを暗号化してしまう可能性があるからである。また、2台の通信装置がいずれも「従」として機能する場合には、いずれか一方の通信装置で最初に用いられた暗号アルゴリズムを双方の通信装置が延々と使いつづけてしまう可能性があるからである。したがって、2台の通信装置間で通信するときには、いずれか一方の通信装置が「主」として機能し、他方の通信装置が「従」として機能するのが好ましい。さらには、CPU等に比較的余力がある側の通信装置が「従」として機能するのが好ましい。なぜなら、「従」として機能する側の通信装置は、自身のCPU使用率に関わらず、常に相手に合わせた負荷の暗号アルゴリズムを用いる必要があるからである。
以下、通信装置154の動作を説明する。なお、以下では、図42に示すように、実施の形態18の通信相手122のように「主」としてのみ機能可能な通信装置172と、実施の形態18の通信装置120のように「従」としてのみ機能可能な通信装置174と、本実施の形態の通信装置154のように「主」と「従」のいずれとしても機能可能な通信装置176とが混在する通信システムにおいて、本実施の形態の通信装置154を利用する場合を想定する。
各通信装置154、172、174、176の暗号情報決定部は、電源駆動時、または通信相手との最初の暗号通信開始時において、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定するためのネゴシエーション(以下、主従折衝と称す)を通信相手と行なう。ただし、このようなネゴシエーションは、通信システムの管理者が手動で行っても構わない。以下では、説明の都合上、ネゴシエーションを開始した側の通信装置を通信装置X、通信装置Xの通信相手を通信装置Yと称す。
各通信装置154、172、174、176の暗号情報決定部は、まず、各通信装置に期待されている役割にしたがって、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定しようと試みる。具体的には、まず通信装置Xの暗号情報決定部は、通信装置Xが「主」にのみなれるか、「従」にのみなれるか、「主」と「従」の両方になれるかを通信装置Yに通知する。通信装置Yの暗号情報決定部は、通信装置Xからの通知を受けると、通信装置Yが通信装置Xに対する適切な通信相手になることができるかどうか判定する。より具体的には、通信装置Xが「主」にのみなれる場合には通信装置Yが「従」になれるかどうか、通信装置Xが「従」にのみなれる場合には通信装置Yが「主」になれるかどうかを判定する。その結果、通信装置Yが通信装置Xに対する適切な通信相手になることができる場合には、その旨を通信装置Xに応答し、主従折衝は終了する。
なお、通信装置Xが「主」と「従」の両方になれる場合には、通信装置Yの暗号情報決定部は、通信装置Yの役割を通信装置Xに応答する。より具体的には、通信装置Yが「主」にのみなれる場合には、その旨を通信装置Xに応答し、通信装置Yが「従」にのみなれる場合には、その旨を通信装置Xに応答する。こうして主従折衝は終了する。
なお、通信装置Xが「主」と「従」の両方になれ、かつ通信装置Yも「主」と「従」の両方になれる場合には、以下の2通りの方法のいずれかにより、自分と通信相手のどちらが「主」となり、どちらが「従」となるかを決定することができる。
第1の方法は、通信装置Yが、予め設定された役割を選択する方法である。具体的には、「主」か「従」のうち、予め設定された方を選択し、その旨を通信装置Xに通知する。通信装置Xは、通信装置Yが「主」を選択した場合には「従」となり、通信装置Yが「従」を選択した場合には「主」となる。こうして主従折衝は終了する。
第2の方法は、双方の処理能力を比較して、処理能力の低い方が「主」となり、処理能力の高い方が「従」となる方法である。この場合、まず、通信装置Yの暗号情報決定部は、通信装置Yの処理能力(例えば、CPU等のハードの能力や、システムに設定された値や、その時点や過去の時点の情報に基づく暗号通信に利用可能なCPUリソースなど)を通信装置Xに通知する。通信装置Xの暗号情報決定部は、この通知を受けて、通信装置Xの処理能力と通信装置Yの処理能力とを比較し、どちらが「主」となり、どちらが「従」となるかを判定する。そして、判定の結果を通信装置Yに通知する。こうして主従折衝は終了する。なお、通信装置Xが通信装置Yに処理能力を通知し、どちらが「主」となり、どちらが「従」となるかを通信装置Yが判定するようにしてもよい。この場合、通信装置Xから通信装置Yへの処理能力の通知は、前述したように、通信装置Xが「主」にのみなれるか、「従」にのみなれるか、「主」と「従」の両方になれるかを通信装置Yに通知するときに、同時に通知するようにしてもよい。
上記のようにして主従折衝が終了すると、通信装置Xの暗号情報決定部は、通信装置Xの役割(「主」か「従」か)に従って動作する。具体的には、通信装置Xが「主」である場合は、図40に示した左側(すなわち通信相手122側)のフローチャートに従って動作し、通信装置Xが「従」である場合は、図40に示した右側(すなわち通信装置120側)のフローチャートに従って動作する。同様に、通信装置Yの暗号情報決定部も、通信装置Yの役割に従って動作する。
以上のように、本実施の形態によれば、2台の通信装置間で通信するときに、この2台の通信装置がいずれも「主」、あるいはいずれも「従」として機能することを防止できる。
なお、上記実施の形態1〜19の説明においては、暗号アルゴリズムの選択ついて説明したが、本発明は、認証アルゴリズムの選択にも適用できる。認証アルゴリズムとは、受信したデータが伝送途中で改ざんされていないことを確認するアルゴリズムである。さらに、本発明は、映像データ・音声データ・一般のデータなどの圧縮・伸長に関する圧縮アルゴリズムの選択にも適用できる。データ圧縮のアルゴリズムとしては、DEFLATEやLZSなど種々のものがあるが、圧縮率、処理負荷およびそのときCPU使用率を考慮して、CPUリソースが枯渇しない範囲でできるだけ圧縮率の高いアルゴリズムを選択することにより、通信回線への負荷を低減することができる。また、別の見方をすると、認証アルゴリズムにおいては、もとの認証対象データに対して複雑な計算を行って認証データを生成するという点で、また圧縮アルゴリズムにおいては、元のデータを圧縮データに変えて複雑な伸長処理を必要とする形にするという点で、いずれも暗号処理に類する点があり、上記実施の形態1〜19を、暗号アルゴリズムの選択に変えて、認証アルゴリズムや圧縮アルゴリズムの選択に適用することが可能である。
また、暗号処理部は、一般的には、IPsec、SSL、TLSなどの暗号通信を実現するプロトコルを1つあるいは複数備え、また、IKEなどの鍵情報取得(IKEは共有鍵交換により鍵情報を取得する。IKEはDiffie−Hellmanアルゴリズムにより鍵交換を実現する。)を行なうプロトコルによるプログラムを1つあるいは複数備えておき、DES−CBC、3DES−CBC、AESなどの暗号アルゴリズムを呼び出して暗号通信を行なうものであればよい。
以下に、特許請求の範囲には明示していないが、以上の記載から読み取れる本発明のいくつかの態様について述べる。
暗号情報決定部は、暗号アルゴリズムの選択時において暗号通信アプリケーションが実行されていない場合に、非暗号通信アプリケーションによる資源使用量として、その時点までの一定期間の使用資源合計値の平均値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において暗号通信アプリケーションが実行中である場合に、非暗号通信アプリケーションによる資源使用量として、その時点までの一定期間の使用資源合計値の平均値から実行中の暗号通信アプリケーションによる資源使用量を引いた値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において実行されている複数の非暗号通信アプリケーションによる資源使用量として、これらの非暗号通信アプリケーションが過去に同じ組み合わせで実行されていた期間におけるこれらの非暗号通信アプリケーションによる資源使用量の平均値を用いるものである。
暗号情報決定部は、暗号アルゴリズムの選択時において実行されている非暗号通信アプリケーションによる資源使用量として、非暗号通信アプリケーションに対して予め既定された値を用いるものである。
暗号情報決定部は、特定の暗号アルゴリズムを用いたときの暗号通信アプリケーションによる資源使用量として、暗号通信アプリケーションが過去に特定の暗号アルゴリズムを用いて実行されていた期間における暗号通信アプリケーションによる使用資源量の平均値を用いるものである。
暗号情報決定部は、特定の暗号アルゴリズムを用いたときの暗号通信アプリケーションによる資源使用量として、暗号通信アプリケーションと特定の暗号アルゴリズムの組み合わせに対して予め既定された値を用いるものである。
スケジュール部は、暗号処理を必要とするアプリケーションである暗号通信アプリケーションに関連するタスクの開始に先立って暗号通信用の鍵を生成する前処理をスケジュールに登録するものであり、かつ暗号アルゴリズムの使用開始予定時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値、あるいは暗号アルゴリズムの切換予定時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値に基づいて、前処理の開始時刻を決定するものである。
スケジュール部は、暗号通信用の更新鍵を生成するためのリキー処理をスケジュールに登録するものであり、かつ暗号通信用の鍵の寿命満了時刻以前の時間帯における使用資源合計値を許容資源使用量から減算した結果の値に基づいてリキー処理の開始時刻を決定するものである。
暗号通信部は、ある暗号アルゴリズムを途中でいったん別の暗号アルゴリズムに切り替えてから再び元の暗号アルゴリズムを使用する場合に、暗号アルゴリズムを切り替える前に使用していた通信用の鍵を、別の暗号アルゴリズムの使用中も保持しておき、再び元の暗号アルゴリズムを使用するときに鍵を再利用するものである。
暗号情報決定部は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から受信した一定数のパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムのうち最も頻度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から過去一定時間以内に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表を参照して、受信したパケットに適用されていた暗号アルゴリズムのうち最も頻度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から最後に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムと比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から受信した一定数のパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値と比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
暗号情報決定部は、通信相手から過去一定時間以内に受信したパケットに適用されていた暗号アルゴリズムを受信履歴管理表に格納し、受信履歴管理表および暗号処理使用資源表を参照して、受信したパケットに適用されていた暗号アルゴリズムの計算量の統計値と比べて計算量が等しいまたは少ない暗号アルゴリズムのうち、最も暗号強度の高い暗号アルゴリズムを選択するものである。
通信装置は、暗号アルゴリズムに替えて、認証処理を行なうための認証アルゴリズムおよび圧縮伸長処理を行なうための圧縮アルゴリズムの少なくとも一方に適応化されたものである。