(57)【要約】【課題】真性乱数発生素子あるいは擬似乱数発生素子を用いた認証用デバイス、例えばＵＳＢトークン、及び、これを用いた認証装置、認証方法、認証システム等を提供する。【解決手段】認証システムでは、ユーザ側に認証用デバイスを用意し、この認証用デバイス内で生成した一方のコードで他方のコードを暗号化する。認証側装置では、前記コードを登録しておき、認証用デバイスからの暗号化されたコードを、この登録したコードを使用して復号化し、認証を行う。【選択図】  図２
2007336506.tif 000002
【特許請求の範囲】
【請求項１】
真性又は擬似乱数を生成する乱数生成部と、この乱数生成部によって生成された少なくとも一つのコードで他のコードを暗号化する制御部とを有する、認証用デバイス。
【請求項２】
前記認証用デバイスは、ＵＳＢ型又はカード型等のトークンであることを特徴とする請求項１に記載の認証用デバイス。
【請求項３】
前記認証用デバイスは、ＵＳＢインターフェイスを備えたカード型のトークンであることを特徴とする請求項２に記載の認証用デバイス。
【請求項４】
請求項１、２又は３に記載の認証用デバイスと、前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、前記認証用デバイス側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う認証装置とからなる認証システム。
【請求項５】
前記認証システムは、更に、前記認証用デバイスを取り外し自在に装着可能であってその認証用デバイスを制御する端末を有することを特徴とする、請求項４に記載の認証システム。
【請求項６】
前記認証用デバイスは、認証中又は認証の完了後、前記乱数発生部によって生成した新たなコードを暗号化することを特徴とする請求項５に記載の認証システム。
【請求項７】
前記認証装置は、認証中又は認証の完了後、前記認証用デバイス側から送られた暗号化された新たなコードを、前記登録したコードを使用して復号化することを特徴とする、請求項６に記載の認証システム。
【請求項８】
請求項１、２又は３に記載の認証用デバイスを取り外し自在に装着できるメールの送信側及び受信側の端末と、メールの送信側及び受信側の前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、メールの送信側及び受信側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行うメールサーバーとからなるメール認証システム。
【請求項９】
認証中又は認証の終了後、メールの送信側では、前記認証用デバイスで生成されたコードを用いてメール本文又はメール本文と添付ファイルを暗号化するために使用するキーを生成し、このキーを使用してメール本文等を暗号化してメールサーバーに送り、前記メールサーバーは、前記登録した送信側のコードを用いてメール本文等を復号化するために使用する前記キーを生成し、このキーを使用して送信側から送られた暗号化されたメール本文等を復号化することを特徴とする請求項８に記載のメール認証システム。
【請求項１０】
前記メールサーバーは、復号化したメール本文等からメールの受信者を確認し、復号化したメール本文等を、前記登録した受信側のコードを用いてメール本文等を暗号化するために使用するキーを生成し、このキーを使用してメール本文等を暗号化し、受信側からのメール送付の要求をまって受信側に送ることを特徴とする請求項９に記載のメール認証システム。
【請求項１１】
メールの送信側及び／又は受信側では、認証中又は認証の完了後、前記乱数発生部によって生成した新たなコードを暗号化することを特徴とする請求項８乃至１０のいずれかに記載のメール認証システム。
【請求項１２】
前記メールサーバーは、認証中又は認証の完了後、前記送信側及び／又は受信側から送られた、暗号化された新たなコードを前記登録したコードを使用して復号化することを特徴とする、請求項１１に記載のメール認証システム。
【請求項１３】
請求項１、２又は３に記載の認証用デバイスを取り外し自在に装着できるユーザー側端末と、前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、前記ユーザー側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う認証装置とからなる映像等配信システム。
【請求項１４】
配信される映像等のコンテンツは、当日又は一定の期間ごとに更新されるコードを用いて生成されるキーを使用して暗号化されて、ユーザーに配信され、前記認証装置は、認証後、映像の配信を許可するときに、前記の当日又は一定の期間ごとに更新されるコードを、前記登録したコードを使用して暗号化してユーザー側に送り、ユーザー側は送られてきた暗号化したコードを復号化し、これを使用して前記キーを生成し、このキーを使用して配信された映像等のコンテンツを復号化することを特徴とする請求項１３に記載の映像等配信システム。
【請求項１５】
ユーザー側は、認証中又は認証の完了後、前記乱数生成部で生成した新たなコードを暗号化することを特徴とする請求項１２又は１３に記載の映像配信システム。
【請求項１６】
前記認証装置は、認証中または認証の完了後、ユーザー側から送られた暗号化された新たなコードを復号化することを特徴とする、請求項１５に記載の映像認証システム。
【請求項１７】
請求項１、２又は３に記載の認証用デバイスを用意し、前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、前記認証用デバイス側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う認証方法。
【請求項１８】
請求項１、２又は３に記載の認証用デバイスを、メールの送信側及び受信側にそれぞれ用意し、前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、送信側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行うメール認証方法。
【請求項１９】
請求項１、２又は３に記載の認証用デバイスを、映像の配信を受けるユーザ側に用意し、前記認証用デバイスで生成されたコードと同じコードを予め又は認証中あるいは認証後に確認することによって登録し、前記認証側から送られた暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う映像等配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、真性乱数発生素子あるいは擬似乱数発生素子を用いた認証用デバイス、例えばＵＳＢトークン、及び、これを用いた認証装置、認証方法、認証システム等に関する。
【背景技術】
【０００２】
認証のたびごとに変化するコード（パスワード）を生成するものとして、ワンタイム・トークンと呼ばれるパスワード生成器が知られている。このワンタイム・トークンを利用した認証システムでは、トークンで発生した一回しか使用できないコード（パスワード）を認証するために、事前に認証する側と、される側でハードウエアやアルゴリズムを共有しておく。
【０００３】
例えば、ユーザーに配布されるトークンに、時計を内蔵し、かつトークン固有の数値（以下  シード）を格納する。トークンはその時計から得られた時刻データとシード（ｓｅｅｄ）の値から特定の計算（アルゴリズム）を行い、特定の時刻にそのトークンにのみ有効なトークンコードを生成する。生成されたトークンコードはあらかじめトークン毎に決められている時間間隔で更新される。
【０００４】
認証側のサーバー（認証マネージャ）は、送られて来たユーザーのＩＤ（暗証番号）とトークンコードを受け取ってそのＩＤとトークンコードを検証してアクセス元が正規ユーザーか否か判断する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、こうしたワンタイム・トークンを利用した認証システムには次のような問題点が指摘されている。
（１）ワンタイム・トークンと認証管理側は時間軸を同期させなければならないので、もし認証管理側に障害が発生した場合は時間軸がずれ認証不能となるおそれがある。そこで、かかる不都合を生じさせないように管理を徹底させる必要があり、管理コストの増大を招く。
（２）ワンタイム・トークンはシードを基にして変更されていくが、そのシードの数には限界があり、ユーザー数を限定してしまう。
（３）シードは或るアルゴリズムにしたがって変動していくので解読される可能性がある。
【課題を解決するための手段】
【０００６】
本発明は、こうした従来の欠陥を解消するために開発されたものである。
【０００７】
本発明に係る認証用デバイスは、真性又は擬似乱数を生成する乱数生成部と、この乱数生成部から少なくとも二つのコードを、また必要に応じ他のコードも読み込み、一方のコードで他方のコードを暗号化する制御部とを有する。
【０００８】
また本発明に係る認証システムは、上記認証用デバイスと、前記二つ又はそれ以上のコードを登録し、認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う認証装置とからなる。
【０００９】
また本発明に係るメール認証システムは、前記認証用デバイスをそれぞれ取り外し自在に装着できる送信側端末と受信側端末と、前記二つ又はそれ以上のコードを登録し、認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行うメールサーバーとからなる。
【００１０】
また本発明に係る映像配信システムは、前記認証用デバイスを取り外し自在に装着できるユーザー側端末と、前記少なくとも二つのコードを予め登録し、認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う認証装置とからなる。
【００１１】
また本発明に係る認証方法は、前記認証用デバイスを用意し、前記二つ又はそれ以上のコードを登録し、認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う。
【００１２】
また発明に係るメール認証方法は、前記認証用デバイスを、メールの送信側及び受信側にそれぞれ用意し、前記二つ又はそれ以上のコードを登録し、送信側の認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う。
【００１３】
また本発明に係る映像配信方法は、前記認証用デバイスを、映像の配信を受けるユーザ側に用意し、前記少なくとも二つのコードを予め登録し、認証用デバイスからの暗号化されたコードを、前記登録したコードを使用して復号化し、認証を行う。
【発明を実施するための最良の形態】
【００１４】
以下添付図面を参照して、本発明の実施の形態のいくつかを説明する。
実施形態１
まず、真性又は擬似乱数の発生装置（以下ＲＰＧという）で発生させた２個のコード（使用するコードの個数は２個に限定されない）を使って認証を行うシステムを説明する。このシステムは、ＵＳＢトークン（ＵＳＢトークン）、ローカル（local）側（ＰＣ）及び認証管理側等で構成される。ここでは、トークン（コード生成用デバイス）は、ＵＳＢトークンを使用するが、その形状はカード型のもの、キーフォブ型のもの等でもよく、形状は特に限定するものではない。後述する他の実施形態でも同様である。
【００１５】
図１は、本実施形態で使用するトークンのブロック図を示す。この例では、インターフェイスはＵＳＢであるが、他のインターフェイスでもよい。
【００１６】
真性ないしは擬似乱数発生素子で発生した２個のコードは、制御部によって読み込まれ、不揮発性メモリに記憶される。制御部は、ＣＰＵ、Ｉ／Ｏ、メモリ・コントローラ等で構成される。不揮発性メモリとしては、フラッシュ（Flash）メモリ 、EEPROM、SRAM 等が使用される。
【００１７】
詳細は後述するが、制御部は、上述の機能の他に、コードを暗号化すること、コードをＵＳＢコントローラ、ＵＳＢコネクタを介しローカル側であるＰＣに送信すること、ＰＣからの指示に従い所定の作業をすること等の機能を有する。なお、ＲＰＧは、例えば特許２９２６５３９号に開示のものを使用する。
【００１８】
本実施形態における認証の手順は次のようにして行われる。
【００１９】
１．初期設定
認証側にＵＳＢトークンで生成された初期の二つのコードＲＰＧ１，ＲＰＧ２を設定する。同時にユーザー名も登録する。
ＵＳＢトークンもそのコードＲＰＧ１，ＲＰＧ２を記録しておく。
ＵＳＢトークンをユーザーに渡す。
ユーザーが多数（無限でもＯＫ）の場合はユーザー数分のＵＳＢトークンで同じ作業を行う。
【００２０】
２．認証
ステップ１：  ＵＳＢトークン内において、コードＲＰＧ１（共通鍵）でＲＰＧ２を暗号化する。
ステップ２：  暗号化されたコードＲＰＧ２（ＥＮ）（認証コード）を、ローカル側を経由して認証管理側に送信する。
ステップ３：  認証管理側では、暗号化されたコードＲＰＧ２（ＥＮ）を、コードＲＰＧ１で復号化する（コードＲＰＧ２（ＤＥ））。そしてこの復号化されたコードがＲＰＧ２に等しいか否か検証する。
ステップ４：  コードＲＰＧ２（ＤＥ）がＲＰＧ２に一致したとき、認証管理側は、ユーザーによるローカル側へのログ・インを許可し、コードＲＰＧ２（ＤＥ）がＲＰＧ２に一致しないときはログ・インを拒否する。
【００２１】
３．新しいコードの設定
ステップ１：  前記「２  認証」のステップ４で、ローカル側のログ・インが完了した後、ＵＳＢトークン内で新たなコードＲＰＧ３を発生させ（ＲＰＧからの読み込み）、これをメモリに記録するとともにコードＲＰＧ１を削除する。ＵＳＢトークン内ではコードＲＰＧ２，ＲＰＧ３が記録される。
ステップ２：  ＵＳＢトークン内でコードＲＰＧ２（新しい共通鍵）でコードＲＰＧ３を暗号化する（暗号化されたコードＲＰＧ３（ＥＮ）を生成）。
ステップ３：  暗号化されたＲＰＧ３（ＥＮ）を認証管理側に送信する。
ステップ４：  認証管理側で、コードＲＰＧ２（新しい共通鍵）で、暗号化されたコードＲＰＧ３（ＥＮ）を復号化する。
ステップ５：  復号化されたＲＰＧ３（ＥＮ）をコードＲＰＧ３として登録する。認証側にはコードＲＰＧ２，ＲＰＧ３が登録される（ＲＰＧ１は削除）。
【００２２】
以後は上記の１乃至３の作業を繰り返す。
【００２３】
このように、本実施形態では、共通鍵も認証コードも、ＵＳＢトークン側と認証管理側とで毎回アクセスされるたびに更新され、かつその更新された同じ共通鍵、認証コードを保有することになるので、高い秘匿性を有した認証システムを実現できる。
【００２４】
また真性乱数を用いることにより、誰にも予測がつかない（誰にも制御できない）コードを使用することができ、完全な秘匿性を有した認証システムを実現できる。
【００２５】
更に、認証コードをＵＳＢトークン内部で暗号化しているので、どのＰＣ（ローカル側）を利用しても認証が可能であり、かつどのＰＣからも安全なサーバー閲覧が行える。
【００２６】
また、本実施形態では、２個のコードを利用していること、認証が終了した瞬間次の新規のコードが登録されること、またＵＳＢトークン内部でのみ２個のコードを保有しＵＳＢトークン内部で暗号化しているのでＰＣを通じて認証請求してもＰＣ内部には復号化鍵が存在しないこと等のため、少なくとも３重のセキュリティーが施され、安全である。
【００２７】
図２は、本実施形態の上述した認証手順をフローチャートとして示したものである。なお図示のフローチャートでは、
（１）System code （例えば64byte）およびClient code （例えば64byte）は記載していない。
（２）Client Codeは便宜上#1および#2と記述する。
（３）＃1RPG1、＃1 RPG2等・・・・暗号化されていないコードを示す。
（４）＃1RPG(EN)1、＃2RPG(EN)2等・・・・暗号化されたコードを示す。
（５）＃1RPG(DE)1、＃2RPG(DE)2等・・・・復号化されたコードを示す。
【００２８】
実施形態２
次に、真性又は擬似乱数発生装置（ＲＰＧ）で生成された２個のコードを使って、本人認証及び平文の暗号化・復号化を行い、完全な秘匿性を確保できるメールサーバーシステムについて説明する。このシステムは、メールの送信者、受信者である２名のクライアント（それぞれが認証用ＵＳＢトークンを所有する）、及びメールサーバー（受信用のＳＭＴＰサーバー及び送信用のＰＯＰサーバー）等で構成される。
【００２９】
まず、このシステムを構成するため、次のような前提条件が設定されているものとする。
（１）あらかじめクライアント（ここでは２名）Client A 、Client Bについて、それぞれ二つのコードＲＰＧＡ１（初回の共通鍵）、ＲＰＧＡ２(初回のＩＤ)およびＲＰＧＢ１(初回の共通鍵)、ＲＰＧＢ２（初回のＩＤ）がメールサーバー側に登録されている。もちろんClient A 、Client Bのメールアドレスのも登録されている。
（２）メールサーバー上に、平文暗号化・復号化アルゴリズムＦＸと、暗号化鍵生成アルゴリズムＦＹがインストールされている。Client A 、Client B の側にもそれぞれ同じ暗号化アルゴリズムがインストールされている。
（３）メールサーバーには認証管理機能がインストールされている。
（４）Client A 、Client B のＵＳＢトークンには、メール本文、添付ファイルを暗号化、復号化するため、充分なメモリ容量、例えば１ギガバイト程度のメモリ空間が確保されている。
（５）必要に応じ、新たに専用のメールアプリケーション（メーラー）を開発する。
【００３０】
本実施形態で使用するＵＳＢトークンは図１のブロック図で示されるものと同様である。
【００３１】
次の本実施形態のシステムの動作について、送信側ユーザー（Client A）、ＳＭＴＰサーバー、ＰＯＰサーバー、受信側ユーザー（Client B）に分けて説明する。
【００３２】
１．送信側ユーザー（Client A）
（１）コードＲＰＧＡ１でコードＲＰＧＡ２を暗号化する（認証コードＲＰＧＡ２（ＥＮ）の生成）。
（２）コードＲＰＧＡ２からアルゴリズムＦＹで暗号化鍵を生成し、送信したいメール本文と添付ファイル（平文）を、この暗号化鍵を使用し、アルゴリズムＦＸによって暗号化する。
（３）暗号化されたコードＲＰＧＡ２（ＥＮ）と、暗号化されたメール本文、添付ファイルをＳＭＴＰサーバーに送信する。
【００３３】
２．ＳＭＴＰサーバー
（１）受信したＲＰＧＡ２（ＥＮ）をコードＲＰＧＡ１で復号化し、本人認証を行う（実施形態１と同様）。
（２）送信側と同様にコードＲＰＧＡ２からアルゴリズムＦＹで暗号化鍵を生成し、受信した、暗号化されたメール本文、添付ファイルを、この暗号化鍵とアルゴリズムＦＸによって復号化する。
（３）送信先のメールアドレスからClient Bが受信者であることを確認する。
（４）Client BのＩＤコードＲＰＧＢ２からアルゴリズムＦＹで暗号化鍵を生成し、復号化されたメール本文、添付ファイルを、この暗号化鍵とアルゴリズムＦＸによって暗号化する。
（５）暗号化したメール本文、添付ファイルをＰＯＰサーバーに転送する。
【００３４】
３．ＰＯＰサーバー
（１）受信側のClient Bからのメール要求（Client Bが端末に自身のＵＳＢトークンを挿入し、メーラー・ソフトを立ち上げることによって発生）をまって、暗号化したメール本文、添付ファイルを受信側ユーザー（Client B）の端末に送信する。
【００３５】
４．受信側ユーザー
（１）コードＲＰＧＢ２とアルゴリズムＦＹで暗号化鍵を生成する。
（２）ＰＯＰサーバーに対しメール要求を行って、暗号化したメール本文、添付ファイルを受信する。
（３）暗号化鍵とアルゴリズムＦＸによって、暗号化したメール本文、添付ファイルを復号化する。
なお、受信側ユーザーとメールサーバーとの間の本人認証は、送信側ユーザーとメールサーバーとの間の本人認証と同様に行うことができる。
【００３６】
５．コードの更新
（１）送信側では、暗号化したメールをメールサーバーに送付した後、ＵＳＢトークン内で、新たなコードＲＰＧＡ３を発生させ（ＲＰＧからの読み込み）、これをメモリに記録するとともにコードＲＰＧＡ１を削除する。ＵＳＢトークン内でコードＲＰＧＡ２，ＲＰＧＡ３を記録させる。
（２）次いで、コードＲＰＧＡ２でコードＲＰＧＡ３を暗号化し（コードＲＰＧＡ３（ＥＮ）を生成）、これをメールサーバーに送信する。
（３）メールサーバーは、コードＲＰＧＡ２でＲＰＧＡ３（ＥＮ）を復号化する。復号化されたＲＰＧＡ３（ＥＮ）をコードＲＰＧＡ３として登録する。サーバーにはコードＲＰＧＡ２，ＲＰＧＡ３が登録される（ＲＰＧＡ１は削除）。
（４）受信側では、暗号化されたメール本文、添付ファイルを復号化した後、ＵＳＢトークン内で、新たなコードＲＰＧＢ３を発生させ（ＲＰＧからの読み込み）、これをメモリに記録するとともにコードＲＰＧＢ１を削除する。ＵＳＢトークン内でコードＲＰＧＢ２，ＲＰＧＢ３を記録させる。
（５）次いで、コードＲＰＧＢ２でコードＲＰＧＢ３を暗号化し（コードＲＰＧＢ３（ＥＮ）を生成）、これをメールサーバーに送信する。
（６）メールサーバーは、コードＲＰＧＢ２でＲＰＧＢ３（ＥＮ）を復号化する。復号化されたＲＰＧＢ３（ＥＮ）をコードＲＰＧＢ３として登録する。サーバーにはコードＲＰＧＢ２，ＲＰＧＢ３が登録される（ＲＰＧＢ１は削除）。
【００３７】
このように、本実施形態では、認証鍵も暗号鍵も、ユーザー側とメールサーバー側で毎回アクセスされるたびに更新されるから、コードの複製、改ざんは不可能で、秘匿性の高く安全なメールシステムが実現できる。また真性乱数を用いることにより、誰にも予測がつかない（誰にも制御できない）コードを使用することができ、かつ認証と暗号化を同時に行っているので、いわゆる「成りすまし」は不可能である。また各ユーザーが他のユーザーの暗号鍵を知ることは不可能であり、人為的な漏洩を完全に防ぐことができる。
【００３８】
更に、認証コードをＵＳＢトークン内部で暗号化しているので、どのＰＣ（ユーザーの端末）を利用しても認証が可能で、かつどのＰＣからも安全なメール取得が行える（使用したＰＣ内部のメールは削除する必要がある）。またＵＳＢトークン内で暗号化されるのでＰＣがインターネットにつながっていても安心である。
【００３９】
更に、メールサーバー側でＲＰＧコードを各ユーザーのＲＰＧコードに変換してくれるので、端末側で全員の共通鍵を有する必要がなく簡便である。
【００４０】
このように、本実施形態では、２個のコードを利用していること、認証が終了した瞬間次の新規のコードが登録されること、またＵＳＢトークン内部でのみ２個のコードを保有しＵＳＢトークン内部で暗号化しているのでＰＣを通じて認証請求してもＰＣ内部には復号化鍵が存在しないこと等のため、少なくとも３重のセキュリティーが施され、安全である。
【００４１】
図３は、本実施形態の上述した認証手順をフローチャートとして示したものである。
【００４２】
実施形態３
次に真性又は擬似真性乱数発生装置（ＲＰＧ）によって生成された２個のコードを使った認証を、ＣＡＴＶあるいはインターネット等のネットワークを経由してストリーミング映像を配信するシステムに応用する場合の実施形態を説明する。
【００４３】
図４は、本発明に係る認証手段を適用する映像配信システムの概要を示すブロック図である。図示のシステムは、ユーザー側端末（ＣＡＴＶのセット・トップ・ボックスあるいはストリーミング受信装置（ＰＣ））、ビデオ・ストリーミング・サーバー（以下サーバーという）、認証マネージャで構成されている。認証マネージャの認証管理機能はサーバーにインストールすることができる。サーバーは、ＣＡＴＶではケーブルＴＶの放送局が対応する。
【００４４】
このシステムにおける認証プロセスは以下の通りである。
（１）ユーザー側から、サーバーに対しログ・オンする。例えば、電源のＯＮと同時にこのプロセスは実行される。
（２）サーバーから、認証マネージャに対しログ・オンの許可を要請する（認証開始）。
（３）認証マネージャは認証の結果、ログ・オンの許可又は拒否の判断をする。
（４）サーバーは、認証の結果、許可の判断がなされると、ユーザー側に対し、ログ・オンを許可し、併せてビデオ・ストリーミング用の暗号を復号するための復号キーを送る。
（５）ユーザー側は、復号キーによって暗号を復号し、ビデオ・ストリーミングのサービスを受けることができる。
【００４５】
図５は、ストリーミング映像を受信するための端末（ＰＣ）の構成を示すブロック図である。この装置は、ＣＰＵ、メイン・メモリ、外部記憶装置、制御ユニット、映像表示装置等で構成されている。制御ユニットは、ＵＳＢやイーサネット（登録商標）等の各種インターフェイス、ストリーム映像処理回路、暗号化/復号化回路、各種デコーダ回路等を含む。
【００４６】
図６は、本発明に係る認証手段を適用した映像配信システムにおける認証手順を示すフローチャートである。
【００４７】
図６は、破線で囲った部分を除き、図２のフローチャートと同様である。ただし、図２の「Local側」は、図６の「Client側」に対応し、前者の「認証管理側」は、後者の「認証管理側＋ビデオ・ストリ−ミング（ビデオ・ストリーミング）側」に対応する（以下、後者においても「認証管理側」と略称する）。また、図６のLocal PCは、ストリーミング受信装置（ＰＣ）を示すが、ＣＡＴＶのセット・トップ・ボックスに置き換え可能である。以下、図６の破線で囲った部分についてのみ説明する。その他の部分の手順は、実施形態１と同様であるので省略する。
【００４８】
ユーザーのＵＳＢトークンをLocal PCに挿入することによって開始された本人認証が済むと、認証管理側は、ＲＰＧ１で、ビデオ・ストリ−ミング用の暗号鍵を暗号化してClient側に送信し、ビデオ・ストリーミングを開始する。
【００４９】
なお、ビデオ・ストリーミング用の暗号鍵（スクランブルコード）も、ビデオ・ストリーミング・サーバー（又はＣＡＴＶの放送局）で、真性又は擬似乱数発生器（ＲＰＧ）から得ることができ、かつ毎日あるいは在る一定時間ごとに更新することができる。またビデオ・ストリーミング用の暗号鍵を暗号化するため使用するコードは、ＲＰＧ２であってもよい（ユーザー側の端末はＲＰＧ１とＲＰＧ２を持っているので、いずれのコードを使用して暗号鍵を暗号化してもでも、ユーザー側で復号化できる）。
【００５０】
一方、Local側のログ・インが完了すると、Client側では、ＵＳＢトークンにＲＰＧ１を要求して得たＲＰＧ１で、認証側から送られてきたビデオ・ストリーミング用の暗号鍵を復号化する。これによって、映像鑑賞を開始することができる。次いで、暗号の復号に使用したＲＰＧ１を破棄し、新しいコードＲＰＧ３の発生をＵＳＢトークンに要求する。
【００５１】
本実施形態は、実施形態１における認証システムと同様に、本人コード（ＩＤ）と共通鍵は、ログインするたびに更新され、かつサーバー側のスクランブルコードも毎回あるいは一定時間毎に更新され、かつ誰も予測がつかず制御できないので、完全にセキュアなシステムを提供できる。
【００５２】
その他、本実施形態のシステムは以下の様な特徴を有する。
（１）ＣＡＴＶあるいはインターネットを利用したビデオ・ストリーミングで有料のコンテンツを視聴する場合、ユーザーの認証を行う必要があるが、その認証はユーザーの端末が変更された場合、例えば郵送で再度認証の申請を行う必要があった。本実施形態では、一回登録すれば、再度認証の申請する必要がなく、どの端末（ＰＣ又はセット・トップ・ボックス（set top box））でも、例えばＵＳＢトークンを挿入することにより使用可能となる。ユーザーは、単にＵＳＢトークンを持ち歩くだけでよい。
（２）このシステムでは他人がなりすましで他人のアカウントでビデオ・ストリーミングのサービスを受けることもできない。
（３）本実施形態のシステムでは、毎回安全な認証を行いかつ毎日１回はビデオ・ストリーミングの暗号鍵を変更できる、またビデオ・ストリーミング用の暗号を解くコードは、ビデオ・ストリーミング用の暗号が復号化されてサービスが開始された直後ＰＣ内部、ＵＳＢトークン、更に認証側でも破棄されて新しいコードが登録されるので安全である。
（４）認証用のコードをＵＳＢトークン内部で暗号化しているのでどのＰＣを利用しても認証が可能であり、かつどのＰＣからも安全にサービスをうけることができる。
【００５３】
このように、本実施形態では、２個のコードを利用していること、認証が終了した瞬間次の新規のコードが登録されること、またＵＳＢトークン内部でのみ２個のコードを保有しＵＳＢトークン内部で暗号化しているのでＰＣを通じて認証請求してもＰＣ内部には復号化鍵が存在しないこと等のため、少なくとも３重のセキュリティーが施され、安全である。
【００５４】
実施形態４
本発明の認証機構を利用した、ビル内の鍵を一括管理する方法について述べる。
１：ひとつのビル（複数でも可）の鍵を全てサーバーで管理することを想定する。
２：トークンの形状はカードタイプでもＵＳＢタイプでも可能である。
３：実施形態１のコードの認証手段を、実際のドアあるいは書庫等の鍵に応用する。
４：ドア番号あるいは書庫番号をあらかじめ設定しておき、真性乱数で発生したコードＲＰＧ１,ＲＰＧ２ と組み合わせることにより場所の特定ができ、かつ１００％偽造できない鍵システムが実現可能となる。
５：スペアキーが必要な場合は、場所の特定コードの組み合わせでなく“スペアキー”のコードを設定しておきどこでも使用可能な鍵を実現できる。かつスペアキーにセキュアポリシーを設定することによりどこでも使用可能な鍵、部屋のドアのみあるいは書庫のみとスペアキーを管理できる。
６：この機構を利用して入退出管理・サーバーログイン管理等との連携も可能になる。７：ＵＨＦ帯のＲＦＩＤと組み合わせるとともに、ビル全体にアンテナを張り巡らせば、どこに誰がいるかも管理可能となる。またトークンを物に張れば重要書類等の保管管理も可能になる。
【００５５】
この実施形態のシステムは１００％偽造不可のであるので完全なセキュアな鍵システムが実現できる。
【００５６】
実施形態５
本発明の認証機構を、デジタル家電における相互機器間の認証に利用できる。ホーム・サーバー、家庭外部からのＰＣ等からのアクセス認証は、デジタル家電内部に、真性乱数発生素子（ＲＰＧ）で生成したコードを実装し、内部のＣＰＵで相互の認証作業を行う、あるいは制御ソフトを含んだマイコン＋真性乱数発生素子(ＲＰＧ)をデジタル家電内部に実装する事で相互認証を行う。
【００５７】
上述した実施形態の多くでは、トークンは、ＵＳＢトークンを使用しているが、その認証機構を、ＧＳＭ携帯電話あるいはＦＯＭＡ携帯電話等で使用されているＳＩＭカードの形状にして実現することもできる。
【００５８】
本願発明に係る認証機構を、ＩＣカードの形状にして、かつ非接触ＩＣカードの機能との組み合わせによって実現することもできる。
【００５９】
本願発明に係る認証機構を、指輪あるいは腕時計の形状にしてかつ非接触で実現することもできる。
【００６０】
上述した実施形態では、真性乱数を２個生成し、これらを認証に利用したが、２個以上の乱数を使用しても、本発明の認証機構を実現することができる。
【００６１】
また真性乱数＋ＰＩＮ（数字あるいは名前あるいは指紋）の組み合わせでも本発明の認証機構を実現することができる。
【００６２】
また、特に各システム固有のシステムコードを例えば１２８バイトのシステムコード領域を設定して、真性乱数と組み合わせることによっても、本発明の認証機構を実現することが可能である。
【００６３】
また、本発明では、各ユーザーごとにセキュアポリシーの設定を可能にすることもできる。
【００６４】
実施形態６
次に、３個のコードを使用して認証を行うシステムを説明する。このシステムは、実施形態１と同様に、ＵＳＢトークン（USB Token）、ローカル（Local）側（ＰＣ）及び認証管理側等で構成される。ただし、ＰＣは、実施形態１を参照すれば容易に適用可能であるので、ここでは、説明を簡便にするため、ＵＳＢトークンと認証管理側との間でコードを転送するものとして説明する。
【００６５】
まず、本実施例の前提となる状況を説明する。
ａ）個人の識別コードを＃１、＃２、・・・、＃ｎとする（個人認証ではなく、例えば機器認証であれば、シリアル番号等を識別コードとする）。
ｂ）真性乱数あるいは擬似乱数として発生される最初のコードを、Ｒ１、Ｒ２、Ｒ３と表現する。
ｃ）暗号化のアルゴリズムとして排他的論理和を例にして説明する。もちろん、他の方式を採用することは可能である。
【００６６】
以下、本実施形態における認証の手順を説明する。
１）初期設定  識別コード＃１として乱数発生装置からＵＳＢトークンに保存された初期コード３個Ｒ１、Ｒ２、Ｒ３を認証管理側に登録する。
２）ＵＳＢトークン側で、コードＲ１とＲ２とを、コードＲ３を鍵（キー・コード）としてそれぞれ暗号化（Ｒ１とＲ２の排他的論理和を演算）し、暗号化したＲ１のコード及び暗号化したＲ２のコードを認証管理側に転送する。
３）認証管理側では、暗号化したこれらのコードを、キー・コードＲ３を使用して復号化（暗号化したコードとＲ３の排他的論理和を演算）し、Ｒ１、Ｒ２を得る。これにより、認証管理側は、ＵＳＢトークン側との間で、同じＲ１、Ｒ２、Ｒ３を有することを確認する。
４）認証管理側は、ＵＳＢトークン側に対し、新たなコードＲ４を生成するよう要求する。
５）ＵＳＢトークンは、乱数発生装置からコードＲ４を得て、このコードＲ４を、コードＲ２、Ｒ３をそれぞれ使用して暗号化し、これらの暗号化したＲ４のコードを認証管理側に転送する。
６）認証管理側は、これらの暗号化したＲ４のコードを、それぞれコードＲ２、Ｒ３を使用して復号化し、その復号化した二つの値が一致したとき、これをＲ４として登録するとともに、ＵＳＢトークン側に認証許可を発行する。
７）次回の認証には、コードＲ２、Ｒ３、Ｒ４が使用されて、上記の手順が繰り返される。
【００６７】
図７は、上記の手順を示す説明図である。なお、図７において、十の字を丸で包んだ記号は、排他的論理和の演算子を示す。
【００６８】
本実施形態の認証の特徴は、以下の通りである。
１回目のコード転送で相手が同じ３つのコードを有していることの確認を行い、２回目のコード転送で相手が正しいＲ２、Ｒ３を所持していることを確認することによって認証を行い、同時に新たなコードＲ４を登録するので、たとえ通信路で上記２回のコード転送を盗聴されたとしても、なりすましは不可能であり、また乱数Ｒ１乃至Ｒ４の間には、何ら関数的な関係がないため解読も不可能である。
【００６９】
実施形態７
実施形態６の機器認証手段を応用したメールサーバーシステムについて説明する。基本的な構成は、実施形態２のメールシステムと同様である。
【００７０】
まず本実施形態の前提となる状況を説明する。
ａ）識別コード＃１、＃２を有する２人のクライアント（＃１さんと＃２さん）がメールを行う。
ｂ）＃１さんも＃２さんは、初期の識別コードとしてそれぞれ３つのコード（＃１Ｒ１、＃１Ｒ２、＃１Ｒ３）（＃２Ｒ１、＃２Ｒ２、＃２Ｒ３）を保存したＵＳＢトークンを所持している。
ｃ）メールサ−バー内にも＃１さんと＃２さんの初期の３つのコードをそれぞれ登録してある。
ｄ）＃１さん、＃２さん及びメールサーバー内には、充分長い平文を暗号化するための充分長い鍵（キー・コード）を生成するアプリケーション（以下関数Ｆで表す）が組み込まれており、それぞれが同じシード（ＳＥＤＤ）で同じ鍵を生成する。
【００７１】
以下、＃１さんが＃２さんにメールを送信する場合の、本実施形態におけるシステムの動作を説明する。
１）＃１さん（初期コード＃１Ｒ１、＃１Ｒ２、＃１Ｒ３を所有）とメールサーバー（認証管理機能がインストールされている）との間で、実施形態６と同様の認証を行う。
２）メールサーバーが＃１さん本人の認証を終えると、＃１さん側は、＃１Ｒ３をＳＥＥＤにしたＦ（＃１Ｒ３）で生成した平文と同じ長さの暗号鍵で、「メール文章＋添付Ｆｉｌｅ＋認識コード＃２（メールアドレスでも可）」を暗号化（例えば排他的論理和による）してメールサーバーに送信する。
３）メールサーバーも＃１さんの＃１Ｒ３を有しており、＃１Ｒ３をＳＥＥＤにしたＦ（＃１Ｒ３）で同じ鍵を生成し、この鍵で一旦「メール文章＋添付Ｆｉｌｅ＋認識コード＃２」を復号化する。
４）メールサーバーは、上記３）の復号化により得た認識コード＃２（メールアドレス）により、当該メールが＃２さん向けのメールであることを確認する。
５）＃２Ｒ３をＳＥＥＤにしたＦ（＃２Ｒ３）で平文と同じ長さの鍵を生成し、この鍵により、復号化された「メール文章＋添付Ｆｉｌｅ＋認識コード＃２」を再度暗号化する。
６）＃２さんがメールを取得する際は、前述と同様の本人認証手続きを行う。
７）本人認証後、＃２さんは、＃２Ｒ３で暗号化された「メール文章＋添付Ｆｉｌｅ」を取得する。
８）＃２さん自身も＃２Ｒ３をＳＥＥＤにしたＦ（＃２Ｒ３）で生成した同じ鍵で、「メール文章＋添付Ｆｉｌｅ」を復号化する。
【００７２】
図８Ａ乃至図８Ｂは、上記の手順を示す説明図である。図８Ａは初期設定時における＃１さん、＃２さん、メールサーバーそれぞれに登録されているコード及び関数Ｆ（Ｘ）（ＸはＳＥＥＤ）等を示す。図８Ｂは、＃１さんの認証終了後における手順を説明するもので、＃１さんには、自身の認証に際し認証管理側（メールサーバ）からの要求に応じて乱数発生装置から得た新たなコード＃１Ｒ４が登録されている（実施例６参照）。＃２さんは、自身の認証終了前の状態である。
【００７３】
このシステムはサーバー側で認証に使用した各個人の認証コード（＃１Ｒ３）をＳＥＥＤにしたＦ（＃１Ｒ３）で平文を暗号化してサーバーに送信する。サーバー側は送信者の認証と同時に送信者の認証に使用した認証コード（＃１Ｒ３）をＳＥＥＤにしてＦ（＃１Ｒ３）を生成し復号化する。復号化した後、＃２さんの認証コード＃２Ｒ３をＳＥＥＤにしてＦ（＃２Ｒ３）で生成した鍵で暗号化する。＃２さんが認証終了後メールを受け取り、認証に使用した認証コード（＃２Ｒ３）をＳＥＥＤにしたでＦ（＃２Ｒ３）で鍵を生成し、その後メールを復号化する。
【００７４】
このように、このシステムは、暗号化・復号化に使用する鍵の生成関数（アプリケーション）Ｆ（Ｘ）のＳＥＥＤをメールサーバーで交換している。
【００７５】
以上述べた本実施形態のメールシステムは以下の特徴を有する。
（ｉ）３個の認証コードを使用することにより安全、確実な本人認証を行うことができる。
（ii）サーバーのみがクライアントそれぞれの認証コード（３個）を有しているので、サーバで、＃１さん、＃２さん用にＳＥＥＤを交換することができる。従って、たとえ通信路で暗号化された文章を盗聴されても復号ＳＥＥＤはなく非常に安全なメールシステムが構築できる。
【００７６】
実施形態８
次に実施形態６の認証システムを利用した映像配信システムを説明する。基本的な構成は実施形態３のシステムと同様である。
【００７７】
本システムにおける前提となる状況は以下の通りである。
ａ）顧客＃１乃至＃ｎの認証用の３個のコードストリーミング・サーバー（認証サーバーを兼務）が所有している。
ｂ）瞬時に充分長い暗号鍵を生成する機構をサーバー側および＃１乃至＃ｎのクライアントが所有している（関数Ｆ（Ｘ））。かつ同じＳＥＥＤで同じ充分長い暗号鍵を生成できる。
ｃ）ビデオ等のコンテンツは、毎日変化するコードをＳＥＥＤｘにしてＦ（ＳＥＥＤｘ）で暗号化されて送信される。
ｄ）認証終了後、サーバーは＃１Ｒ３、＃２Ｒ３、・・・で復号化用の、毎日変化する鍵生成用のＳＥＥＤｘを暗号化して、各クライアントに送付する。
ｅ）クライアント側はそのＳＥＥＤｘを復号化し、これを用いて復号化鍵Ｆ（ＳＥＥＤｘ）を生成する。
ｆ）ストリーミング開始後、送られてきたコンテンツをＦ（ＳＥＥＤｘ）で復号化を行い再生する。
図９は上記の手順を示す説明図である。
【００７８】
このシステムでは、常時、認証時に変化する認証用のコードをサーバー側とクライアント側が共通して所持し、またコンテンツの暗号化用に提供される関数Ｆ（Ｘ）もサーバー側と認証側が共通して所持する。そして、認証用に利用した共通のコードで、当日のコンテンツ暗号化用の関数Ｆ（Ｘ）のＳＥＥＤを暗号化してクライアント側に送るから、極めて安全な映像配信システムが構築できる。
【００７９】
実施形態９
次に、２個のコードを使用して認証を行うシステムの別の実施形態を説明する。このシステムは、実施形態１と同様に、ＵＳＢトークン（USB Token）、ローカル（Local）側（ＰＣ）及び認証管理側等で構成される。ただし、ＰＣは、実施形態１を参照すれば容易に適用可能であるので、ここでは、説明を簡便にするため、ＵＳＢトークンと認証管理側との間でコードを転送するものとして説明する。
【００８０】
まず、本実施例の前提となる状況を説明する。
ａ）個人の識別コードを＃１、＃２、・・・、＃ｎとする（個人認証ではなく、例えば機器認証であれば、シリアル番号等を識別コードとする）。
ｂ）真性乱数あるいは擬似乱数として発生される最初のコードを、Ｒ１、Ｒ２と表現する。
ｃ）暗号化のアルゴリズムとして排他的論理和を例にして説明する。もちろん、他の方式を採用することは可能である。
【００８１】
以下、本実施形態における認証の手順を説明する。
１）初期設定  識別コード＃１として乱数発生装置からＵＳＢトークンに保存された初期コード２個Ｒ１、Ｒ２を認証管理側に登録する。
２）ＵＳＢトークン側で新たなコードＲ３を生成し、コードＲ１とＲ２とを、コードＲ３を鍵（キー・コード）としてそれぞれ暗号化（Ｒ１とＲ３、Ｒ２とＲ３のそれぞれの排他的論理和を演算）し、暗号化したＲ１のコード及び暗号化したＲ２のコードをマージして認証管理側に同時転送する。
３）認証管理側では、暗号化したこれらのコードを、コードＲ１、Ｒ２を使用してそれぞれ復号化（排他的論理和を演算）する。その結果が同じＲ３であることを確認すると、認証管理側は、Ｒ３を登録するとともに、ＵＳＢトークン側に認証許可を発行し、Ｒ３に更新を許可する。
４）次回の認証には、コードＲ２、Ｒ３が使用されて、上記の手順が繰り返される。
図１０は上記手順を示す説明図である。
【００８２】
この実施形態は、２つのコードと認証時に新たに生成される１つのコードとの合計３つのコードを使用して認証を１回で行うシステムである。このシステムでは、通信路でコード転送を盗聴されても、Ｒ１／Ｒ２／Ｒ３の間には何ら関数的な関係がないため、解読も、なりすましもできない。
【００８３】
この実施形態の認証方法は、実施形態７のメールシステムにも、また、実施形態８の映像配信システムにも適用できることは勿論である。
【００８４】
実施形態１０
次に、３個のコードを使用して認証を行うシステムの別の実施形態を説明する。このシステムは、実施形態１と同様に、ＵＳＢトークン（USB Token）、ローカル（Local）側（ＰＣ）及び認証管理側等で構成される。ただし、ＰＣは、実施形態１を参照すれば容易に適用可能であるので、ここでは、説明を簡便にするため、ＵＳＢトークンと認証管理側との間でコードを転送するものとして説明する。
【００８５】
まず、本実施例の前提となる状況を説明する。
ａ）個人の識別コードを＃１、＃２、・・・、＃ｎとする（個人認証ではなく、例えば機器認証であれば、シリアル番号等を識別コードとする）。
ｂ）真性乱数あるいは擬似乱数として発生される最初のコードを、Ｒ１、Ｒ２、Ｒ３と表現する。
ｃ）暗号化のアルゴリズムとして排他的論理和を例にして説明する。もちろん、他の方式を採用することは可能である。
【００８６】
以下、本実施形態における認証の手順を説明する。
１）初期設定  識別コード＃１として乱数発生装置からＵＳＢトークンに保存された初期コード３個Ｒ１、Ｒ２、Ｒ３を認証管理側に登録する。
２）ＵＳＢトークン側で、コードＲ１とＲ２とを、コードＲ３を鍵（キー・コード）としてそれぞれ暗号化（Ｒ１とＲ２の排他的論理和を演算）し、暗号化したＲ１のコード及び暗号化したＲ２のコードをマージして又は別個に認証管理側に送る。
３）認証管理側では、暗号化したこれらのコードを、キー・コードＲ３を使用して復号化（暗号化したコードとＲ３の排他的論理和を演算）し、Ｒ１、Ｒ２を得る。これにより、認証管理側は、ＵＳＢトークン側との間で、同じＲ１、Ｒ２、Ｒ３を有することを確認する。
４）ＵＳＢトークン側で生成した新たなコードＲ４を、コードＲ２とＲ３をそれぞれ鍵（キー・コード）として暗号化（Ｒ４とＲ２、Ｒ４とＲ３のそれぞれの排他的論理和を演算）し、二つの暗号化したＲ４のコードをマージしてまたは別個に認証管理側に送る。
５）認証管理側では、暗号化したこれらのコードを、コードＲ２、Ｒ３を使用してそれぞれ復号化（排他的論理和を演算）する。その結果が同じＲ４であることを確認すると、認証管理側は、Ｒ４を登録するとともに、ＵＳＢトークン側に認証許可を発行し、Ｒ４に更新を許可する。
６）次回の認証には、コードＲ２、Ｒ３、Ｒ４が使用されて、上記の手順が繰り返される。
なお、上記２）及び４）で得た暗号化したコードは、マージして一緒に認証管理側に送るようにしてもよい。これにより、コード転送の回数を減らすことができる。
図１１は、上記手順を示す説明図である。
【００８７】
本システムでは、上記３）において、Ｒ４＝Ｒ４であればＲ２およびＲ３が正しいことを示していることを利用し機器認証を行っており、Ｒ２とＲ３は何の数学的な関係がなく（真性乱数又は擬似乱数を使用しているので）、計算上的安全が確保されている。言い換えれば通信路でコード転送を盗聴されても、Ｒ１／Ｒ２／Ｒ３の間には何ら関数的な関係がないため、解読も、なりすましもできない。
この実施形態の認証方法は、実施形態７のメールシステムにも、また、実施形態８の映像配信システムにも適用できることは勿論である。
【００８８】
実施形態１１
本発明に使用する認証用デバイスとして、ＵＳＢインターフェイスを備えたカード型のトークンを使用できる。例えば、ＵＳＢインターフェイスの接続端子をカードの周縁部に埋設したクレジット・カード又は個人認証カードが考えられる。この場合、ＰＣで認証を行うときは、ＰＣとこのカードをインターフェイス・ケーブル（カスタム仕様の延長ケーブル又はコネクタ）で接続する。従来のクレジット・カード型の認証カードを使用する場合は、非接触型・接触型を問わず常にカード・リーダが必要であり、これは形状が大きく携行に不便であり、また高価であったが、本実施形態の場合は、延長ケーブル又はコネクタでよく、サイズは小さく、また安価であるから、きわめて利便性に良い。
【００８９】
また、このＵＳＢインターフェイスを備えたカードは、例えば、ｅコマース（電子商取引）で商品を購入する場合等にも利用でき、カード番号をＰＣから入力させないので、情報漏洩の恐れがない（それ故、かかるＵＤＢインターフェイスを備えたカードは銀行カード、クレジット・カード等に応用可能である）。
【図面の簡単な説明】
【００９０】
【図１】本発明で使用するＵＳＢトークンのブロック図を示す。
【図２】本発明の第１の実施形態の認証手順を示すフローチャートである。
【図３】本発明の第２の実施形態の認証手順を示すフローチャートである。
【図４】本発明の第３の実施形態での映像配信システムの概要を示すブロック図である
【図５】本発明の第３の実施形態における、ストリーミング映像を受信するための装置（ＰＣ）の概要を示すブロック図である。
【図６】本発明の第３の実施形態の認証手順を示すフローチャートである。
【図７】本発明の第６の実施形態の認証手順を示す説明図である。
【図８Ａ】本発明の第７の実施形態の認証手順を示す説明図である。
【図８Ｂ】本発明の第７の実施形態の認証手順を示す説明図である。
【図９】本発明の第８の実施形態の認証手順を示す説明図である。
【図１０】本発明の第９の実施形態の認証手順を示す説明図である。
【図１１】本発明の第１０の実施形態の認証手順を示す説明図である。
【図１】
2007336506.tif 000003
【図２】
2007336506.tif 000004
【図３】
2007336506.tif 000005
【図４】
2007336506.tif 000006
【図５】
2007336506.tif 000007
【図６】
2007336506.tif 000008
【図７】
2007336506.tif 000009
【図８Ａ】
2007336506.tif 000010
【図８Ｂ】
2007336506.tif 000011
【図９】
2007336506.tif 000012
【図１０】
2007336506.tif 000013
【図１１】
2007336506.tif 000014