(57)【特許請求の範囲】
【請求項１】
証明書／私用鍵をトークンに割り当てる方法であって、
証明書／私用鍵認証局によってコンピュータシステムに接続されたトークンリーダを介して前記トークンにアクセスし、
前記トークンからトークンＩＤおよびユーザ署名証明書を読み出し、
信頼データベース内で前記トークンＩＤと前記署名証明書の整合をサーチし、
前記トークンＩＤに関する公開鍵でラップされた証明書を生成し、前記認証局の署名証明書を用いて前記証明書／私用鍵にデジタル署名し、
前記証明書／私用鍵を前記トークンにダウンロードし、
前記トークンに格納されている私用鍵を用いて前記証明書／私用鍵を復号化する、
ことを含む方法。
【請求項２】
前記証明書／私用鍵は、少なくとも１つの証明書／私用鍵がユーザのための署名証明書、ユーザのための暗号化証明書／私用鍵、ユーザのためのロール証明書／私用鍵である複数の証明書／私用鍵である、請求項１に記載の方法。
【請求項３】
前記トークンの前記公開鍵でラップされた証明書は、暗号化された証明書である、請求項２に記載の方法。
【請求項４】
前記トークンはスマートカードである請求項３に記載の方法。
【請求項５】
前記トークンＩＤは、前記トークンの生成時にトークンの製造業者によって割り当てられ、ユーザに割り当てられる際に前記信頼データベースに格納される請求項４に記載の方法。
【請求項６】
前記証明書／私用鍵を前記トークンにダウンロードは、セキュアでない通信回線を介して行われる、請求項５に記載の方法。
【請求項７】
前記トークンに格納されている私用鍵を用いて前記証明書／公開鍵を復号化することはユーザによるパスフレーズの入力を要する、請求項６に記載の方法。
【請求項８】
前記認証局の署名証明書を用いて前記証明書／私用鍵に署名をすることにより、前記証明書／私用鍵は前記認証局によって発行されたと認証することをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、包括的には、トークン使用可能公開鍵インフラストラクチャ（ＰＫＩ）システムにおけるユーザ証明書／私用（秘密）鍵の割り当て方法に関し、より詳細には、トークン使用可能ＰＫＩシステムにおける、暗号化署名およびロール証明書／私用鍵の作成、転送、割り当ておよび管理の方法およびコンピュータプログラムに関する。
【０００２】
【従来の技術】
何世紀にもわたって、個人、政府および企業エンティティは、機密に関わる情報を、遠距離の許可された第三者に伝達し、機密保護された機構および技法を求めてきた。上記のエンティティが直面する問題は、情報を必要とする個人あるいはエンティティに如何に情報を伝達し、しかも伝達される情報が傍受された場合であっても、許可されない第三者がその情報を如何に理解できないようにするかということである。情報をセキュア（安全）にする初期の方法は、スクランブル技法、ルックアップテーブル、換字式暗号および情報内の元の文字および語句の代わりに別の文字および語句が用いられるコードブックを用いていた。これらの技法は多くの場合に、情報の送り手および受け手のいずれもが同じ「コードブック」にアクセスすることを必要とした。そのような技法には、コードブックが許可されない第三者の手に渡るという危険性があった。
【０００３】
２０世紀の前半、特に第二次世界大戦中には、コードブックの代わりに電気機械式の暗号機が用いられた。情報の送り手および受け手は、送信されるメッセージを暗号化および復号化（解読）するために同一の暗号機を用いていた。これらのメッセージの復号化をさらに困難にするために、暗号機は、メッセージ内で用いられる暗号を変更するか、あるいはメッセージ内の数ワード毎に用いられる暗号を変更する能力を備える。これを成し遂げるために、暗号機は、初期状態あるいはメッセージを暗号化するために用いられる鍵を知る必要があった。
【０００４】
最近では、暗号機の代わりにデジタル暗号化アルゴリズムが用いられており、情報の送り手および受け手はいずれも、同じデジタル暗号化アルゴリズムを複製したものと、メッセージを暗号化および復号化するために用いられる共通鍵とを有する。暗号化アルゴリズムおよび鍵はいずれも、送り手および受け手の双方によって秘密に保持される。
【０００５】
さらに最近では別の暗号化技法が開発されており、その技法においては暗号化および復号化のために２つの個別の鍵が用いられる。公開鍵は、それを必要とする人がいれば誰にでも自由に送信され、特定の受け手へのメッセージを暗号化するために用いられる。情報の受け手は、関連する公開鍵で暗号化されたメッセージを復号化するために用いられる場合がある、関連する私用（個人用）鍵を有することになる。各公開鍵に対して秘密（私用）鍵は１つだけ存在し、各私用鍵に対して公開鍵は１つだけ存在する。送り手が数人の受取人に１つのメッセージを送信するとき、各受取人の公開鍵を所持する必要がある。その際、そのメッセージは各受取人の公開鍵を用いて個別に暗号化され、その特定の受取人に送信されることになる。それゆえ、１０個の個別のエンティティが同じメッセージを受信することになる場合には、個々の公開鍵でそれぞれ暗号化された１０個の個別のメッセージが送信されることになる。参照によりその全体を本明細書に援用するHousley等による「Internet X.509 Public Key Infrastructure」というタイトルのＲＦＣ２４５９に説明されるように、インターネットの出現によって、そのような公開鍵インフラストラクチャが広く採用されるようになった。
【０００６】
メッセージの暗号化および復号化に対する必要性に加えて、電子メールおよびインターネットの出現によって、個人による承認および受諾を指示するために、セキュア（安全）機構に対する必要が生じた。これまでは、個人は一般に、手書きの署名、証印あるいはその個人のみが保有する印鑑を用いて、契約書あるいは注文書のような条項の承認あるいは受諾を示している。他人がそのような署名、証印あるいは印鑑を偽造しようとすれば、刑罰を受けるであろう。電子メールおよびインターネットの出現によって、適当な認証機関を用いて人あるいはエンティティが契約あるいは購入の承認あるいは受諾を指示するために、電子メールの容易性および迅速性を利用する必要が生じてきた。これは、個人がある文書にデジタル処理で署名を行うことができるデジタル（電子）署名として知られるようになった。
【０００７】
このデジタル署名の機能は、先に説明された同じ公開鍵インフラストラクチャを用いて実施されている。しかしながら、文書全体を暗号化する代わりに、文書そのものは、ダイジェストと呼ばれる短い文書を生成する一方向ハッシュアルゴリズムを通して渡される。その際、このダイジェストは私有署名鍵としても知られる個人の私用鍵を用いて暗号化され、その文書に添付される。文書の受け手は、文書から署名を取り除き、その文書においてハッシュ関数を計算し直して、受け取られたダイジェストを生成することにより、デジタル署名（ダイジェスト）の信憑性を検証することができる。その文書に含まれるか、あるいは予め受信している公開署名鍵を用いて、その文書のダイジェストを復号化し、それを計算し直したダイジェストと比較することができる。２つのダイジェストが一致する場合には、その署名は認証され、受信された文書は送り手によって署名された文書と同じものであることが証明される。それゆえ上記の公開鍵基盤を用いて、メッセージおよびデジタル署名された文書を暗号化し、それを復号化することができる。
【０００８】
しかしながら、上記の公開鍵インフラストラクチャにはいくつかの制限がある。そのような１つの制限は、個人あるいはエンティティのグループが暗号化されたメッセージを送受信するために、各個人が、公開鍵および私用鍵を有する鍵ペアを作成していなければならないことである。さらにあるグループに属する各個人あるいはエンティティは、文書にデジタル署名するために、個別の公開署名鍵および私有署名鍵を所持する必要もある。グループの他の構成員が、受信したメッセージを復号化できるようにするために、そのグループの構成員は私用鍵を含む鍵対（ペア）を交換する必要がある。これは、そのグループの構成員が病気あるいは旅行によってオフィスに不在であるときに必要な場合がある。そのような鍵ペアの交換が行われない場合、暗号化された緊急のメッセージがたとえば企業の財務部、人事部あるいは技術部門に到着したときでも、私用鍵を保有する人しかそのメッセージを復号化できない恐れがある。その人が不在であるとき、そのメッセージは復号化されず、送り手は迅速な回答を受け取ることができないであろう。しかしながら、グループの構成員によって鍵ペアが交換されるとき、そのメッセージの性質あるいはその秘密性に関係なく、個人の私用鍵を所持する全ての構成員がその人に送信された全てのメッセージを復号化することができる。これは、顧客の要求に迅速に対応する必要があり、かつ顧客の信頼を保持しなければならない取引において大きな問題を生み出す。これは、応答の配信の遅れで著しく費用がかかることにつながる場合がある法律事務所、診療所および軍において最も深刻になる場合がある。さらに、個人あるいはエンティティの大きなグループの中で互いに鍵ペアを交換することは厄介である。たとえば、グループが３０人の個人を含む場合、そのグループ内の誰もがグループの任意の他の構成員によって受け取られる任意のメッセージを復号化できるようにするためには、全部で３０×３０、すなわち９００回の鍵ペアの交換が行われなければならない。
【０００９】
現存する別の制限は、証明書／私用鍵の安全性および可搬性に関連する。一般に、ユーザに割り当てられる証明書／私用鍵は私用鍵および公開鍵の両方を含み、それぞれコンピュータに格納される。これらの証明書／私用鍵は多くの場合に、それらが格納されるコンピュータシステム内にその使用が制限される。それゆえ、ユーザが別のコンピュータシステムを利用したい場合には、そのユーザは自分の証明書／私用鍵をそのシステムに移動させなければならない。さらに、インターネットに接続したパーソナルコンピュータは、許可されない第三者による侵入および破損を受けやすくなることがわかっている。それゆえ、私有および公開暗号化および署名証明書／私用鍵がインターネットに直接的あるいは間接的に接続されるパーソナルコンピュータに格納される場合には、証明書／私用鍵を複製し、多少の労力によって証明書／私用鍵を用いるために必要とされるパスフレーズを決めることができる。
【００１０】
これらの証明書／私用鍵に対するさらに別の制限としては、新しい証明書／私用鍵の生成が、高度のセキュリティを望む場合にセキュリティオフィサーによってのみ行われるか、またはリモートコンピュータにおいて行われ、セキュリティを提供するパスワードによってユーザのコンピュータにダウンロードされるということである。セキュリティオフィサーを用いることは、費用および時間がかかる。なぜなら、被雇用者は約束を取り付け、オフィサーに会い、本人であることを確認し、その後証明書／私用鍵を受け取らなくてはならないからである。パスワードセキュリティだけを用いて証明書／私用鍵をダウンロードすることは、トロイの木馬として知られるタイプのプログラムが用いられる場合に特に危険が高い。この「トロイの木馬」は、コンピュータシステム上に格納されている証明書／私用鍵を傍受（インターセプト）またはそれにアクセスし、無許可の者へと転送する場合がある。
【００１１】
転送証明書／私用鍵をユーザに対して安全（セキュア）に転送するために使用される方法には、さらなる制限がある。一般的なＰＫＩアーキテクチャでは、一意の（ユニークの）Ｘ．５０９私用鍵および鍵暗号化証明書が各サーバプラットフォームに対して発行される。これは、サーバプラットフォームとクライアントプラットフォームの間でセキュア・ソケット・レイヤー（ＳＳＬ）セッションを作成するために使用され、これによりこれらの２つのプラットフォームの間で転送される全てのデータが暗号化され、セキュアとなるようにする。しかしながら、データ経路のいわゆる最後の「６インチ」が暗号化されないかまたはセキュアではない、すなわち私用鍵の格納は、鍵が平文であり、まだ暗号化されていない場合に行われ得るため、重大なセキュリティ制限が存在する。
【００１２】
したがって、クライアントプラットフォームは主に脆弱性が生じる場所である。クライアントプラットフォーム上で不正に作動するウイルスまたはトロイの木馬のような悪性コードは、サーバプラットフォームと行先格納媒体の間で転送されるデータを破壊、置換、あるいはインターセプトする可能性がある。
【００１３】
【発明が解決しようとする課題】
したがって、あらゆるタイプの証明書／私用鍵をセキュアな方法で作成、転送、かつ格納することのできる方法およびコンピュータプログラムが必要とされている。本方法およびコンピュータプログラムは、ユーザアイデンティティの検証、または任意の証明書／私用鍵の作成あるいはダウンロードに対するセキュリティを提供するためのセキュリティオフィサまたは他の人員を必要としないものとする。さらに、本方法およびコンピュータプログラムは、ユーザがアクセスするコンピュータシステム上に存在する場合があるウイルスあるいは「トロイの木馬」タイプのウイルスに対してセキュアであるものとする。
【００１４】
【課題を解決するための手段】
本発明の教示によると、証明書／個人用（私用）鍵が生成され、公開鍵でラップされ、トークンのみが含む私用鍵を用いて証明書を活性化し得るトークンへ転送され得る方法およびコンピュータプログラムが開示される。
【００１５】
さらに、本発明によると、トークンに証明書／私用鍵を割り当てるための方法およびコンピュータプログラムが開示される。本方法およびコンピュータは、認証局によってコンピュータシステムに接続されたトークンリーダを介してトークンにアクセスすることで開始する。次に、トークンリーダはトークンからトークンＩＤおよび署名証明書を読み取る。信頼すべきデータベース中でトークンＩＤと署名証明書の一致（整合）について探索（サーチ）が行われる。トークンＩＤに関する公開鍵にラップされ、認証局の署名証明書を用いて認証局によってデジタル署名された証明書／私用鍵が作成される。証明書／公開鍵はトークンにダウンロードされる。次に、証明書／私用鍵は、トークンに格納されている私用鍵を用いて復号化される。
【００１６】
本発明のさらに別の目的、特徴および利点は、添付の図面に関連して以下に記載される説明および請求の範囲から明らかになるであろう。
【００１７】
【発明の実施の形態】
トークンの失効および更新のためのプロセスに向けられる以下に記載される実施例の説明は実際には例示にすぎず、決して本発明あるいはその応用形態または用途を限定することを意図するものではない。
【００１８】
本発明の詳細な説明を始める前に、以下の点を簡単に説明しておく必要があるであろう。適当な場合には、異なる図面において、類似の参照番号および符号が同一の構成要素、対応する構成要素あるいは類似の構成要素を指示するために用いられる場合がある。さらに、以下に記載される詳細な説明では、典型的な寸法／モデル／値／範囲が与えられる場合があるが、本発明はそれらに限定されない。
【００１９】
流れ図の説明に入る前に、ロール（role）証明書の特性、機能および構造に関して簡単に説明しておく必要がある。図２ないし図４を検討することから明らかになるように、本発明の実施形態は、先に参照して本明細書に援用されたＲＦＣ２４５９の第４項に詳細に説明されるＸ．５０９証明書（Ｖ３）に基づく。Ｘ．５０９証明書は、暗号化するために、あるいは署名鍵として用いられる公開鍵証明書である。Ｘ．５０９証明書に含まれる情報は、署名証明書として構成されるか、暗号化のために公開鍵として構成されるかによって変更されるであろう。ロール証明書は、少なくとも以下の表１に示されるフィールドを含む。
【００２０】
【表１】
0004625234.tif 000002
【００２１】
ロール証明書は３つの態様でＸ．５０９証明書（Ｖ３）から区別される。第１に、ロール証明書の名はロール証明書としてそれを区別する場合がある。第２に、表１に示される拡張領域フィールド内のビットは、ロール証明書が暗号化および署名の両方の目的のために用いられる場合があることを指示するように設定されるであろう。第３に、ロール証明書の使用上の制限を指示するためのポリシーがロール証明書に関連付けられる場合がある。これらのポリシーは、あるオフィスに関連する署名証明書を受け取る、図１に示されるユーザ１３２がアクセス可能な登録ウェブサーバ１２４上に格納される場合がある。たとえば、ロール証明書は、購入要求を承認するために企業内の財務部によって発行される場合がある。しかしながら、財務部内の数人が署名のようなロール証明書を発行する場合があるので、そのロール証明書は、１０万ドルの場合には有効であり、それより高額の場合には有効ではないような、ドル制限ポリシーを関連付けることができる。ドル制限より高い額は、有効と見なされるためには財務責任者の個別の署名証明書が必要とされるであろう。個別の状況に応じて、他の制限がロール証明書に対して関連付けられる。それゆえ、ロール証明書は、ロール証明書のために用いられる命名規則のうちの任意の１つあるいは組み合わせと、ロール証明書に関連付けられ、その使用を制限するポリシーと、拡張領域内のビットを設定することにより暗号化およびデジタル署名の両方の場合にロール証明書を用いるための能力と、暗号化、復号化およびグループ署名のための一群の個人による使用とによってＸ．５０９（Ｖ３）証明書から区別することができる。
【００２２】
図１は本発明の一実施形態において用いられるソフトウェア、ファームウェアおよびハードウェアのモジュール構成図である。図１に示されるブロックは、プロセッサ搭載システム（単数または複数）によって実行可能である、限定はしないが、Ｃ＋＋のようなプログラミング言語で書くことができるモジュール、コード、コードセグメント、コマンド、ファームウェア、ハードウェア、命令およびデータを表す。図１に示されるモジュールは個別のサーバプラットフォームに収容されるものとして示されることに留意されたい。しかしながら、これらのモジュールは個別のサーバに常駐することに限定されず、そのシステムが対処しなければならないユーザの数と、関連する通信とに応じて、１つあるいは任意の数のコンピュータに常駐し、動作することができる。図２ないし図５は、図１に示されるモジュールによって実行される動作をさらに詳述する流れ図およびモジュール構成図である。
【００２３】
図１は、本発明の公開鍵インフラストラクチャ（ＰＫＩ）処理を実施することができる典型的なアーキテクチャ１００を示す。しかしながら、先に説明されたように、本発明は図１のアーキテクチャ１００に限定されないことを理解されたい。アーキテクチャ１００は、サーバプラットフォーム１０６上に常駐する信頼できる（権威）データベース１０４のためのデータエントリ機能を実行するデータエントリ１０２を含む。この説明ではサーバプラットフォーム１０６が参照されるが、本発明が任意の特定のサーバアーキテクチャに限定されないことは理解されたい。サーバプラットフォーム１０６には、限定はしないが、ＵＮＩＸ（Ｒ）あるいはＷｉｎｄｏｗｓ（Ｒ）ＮＴサーバが用いられる場合がある。信頼データベース１０４は、本発明によるＰＫＩサービスが実行されるグループあるいは企業の構成員についての情報を含む。本発明は、その情報が信頼データベース１０４に格納されるグループあるいは企業の構成によって制限されない。信頼データベース１０４の情報は、限定はしないが、グループあるいは企業の構成員の名前、住所、電話番号、経営者の名前、従業員身分証明証番号等を含む。ディレクトリ１０８はデータベースの構造を有するが、データエントリを高速に行うためよりは、その中に格納される情報を高速に探索するために最適化される。ディレクトリ１０８内のデータは頻繁に変更されるのではなく、迅速にアクセスされる必要があり、信頼すべきデータベース１０４に格納されるグループあるいは企業の構成員についての照会情報を含む、「高速の電話帳」としてオンラインで機能する。認証局１１０は、後にさらに詳細に記載されるように、本発明によって用いられる証明書／私用鍵および関連する情報を保管する、サーバプラットフォーム１０６上で実行される従来の既製のソフトウェアである。登録局１１２も、後にさらに詳細に説明するように、本発明によって実行される登録に関する、サーバプラットフォーム１０６上で実行される既製のソフトウェアである。登録ウェブページ１２２は１つあるいは複数のページの場合があり、図１のアーキテクチャ１００へのユーザインターフェースとして機能する。ウェブサーバ１２４は、限定はしないが、アパッチ（Ａｐａｃｈｅ）あるいはマイクロソフト・インターネット・インフォメーション・サーバでも良いウェブブラウザクライアントに、ウェブページ１２２あるいは他のＨＴＭＬ出力のようなウェブページを提供するソフトウェアプリケーションである。ウェブブラウザ１２６は、任意のユーザコンピュータでも良いクライアントプラットフォーム１２８に常駐する。ウェブブラウザ１２６は、限定はしないが、ＨＴＭＬまたはＸＭＬプロトコルあるいは他のプロトコルのような、ウェブページをブラウジングするためのクライアントソフトウェアプリケーションである。ウェブブラウザ１２６は、認証局１１０によって発行されるＰＫＩ証明書／公開鍵を用いて動作するようにプログラミングされる。この機能を有するウェブブラウザの例には、ネットスケープ・ナビゲータおよびマイクロソフト・インターネット・エクスプローラがある。トークン１３０は、ＰＫＩ証明書／私用鍵を生成し、格納し、使用することができるスマートカード、あるいは他のハードウェアトークンである。ユーザ１３２はアーキテクチャ１００の利用者である。ユーザ１３２は、新規ユーザ、現在ユーザ、およびもはやグループあるいは企業の構成員ではない過去ユーザを含む多数の状態の間を移行する。個人失効局１４４は、ネットワーク１００から構成員を失効させる担当者である。個人登録局１４６は、ネットワーク１００において構成員を登録する担当者である。
【００２４】
さらに図１を参照すると、上述したように、ユーザのトークン１３０と認証局１１０のサーバプラットフォーム１０６との間でユーザ１３２のための私用鍵をセキュアに転送するために用いられる従来の方法にはある制限がある。一般的なＰＫＩアーキテクチャでは、一意のＸ．５０９私用鍵および鍵暗号化証明書が各サーバプラットフォーム１０６に対して発行される。これは、サーバプラットフォーム１０６とクライアントプラットフォーム１２８との間にセキュア・ソケット・レイヤ（ＳＳＬ）セッションを生成し、これら２つのプラットフォーム間で転送される全てのデータが暗号化され、セキュアになるようにするために発行される。しかしながら、データ経路の最後の「６インチ」、すなわちトークン１３０とそれが取り付けられるクライアントプラットフォーム１２８との間の経路が暗号化されないか、あるいはセキュアでないため、そのセキュリティには大きな制限がある。そのデータは典型的には平文で転送される。
【００２５】
それゆえ、さらに図１を参照すると、クライアントプラットフォーム１２８は主に脆弱性が生じる場所である。クライアントプラットフォーム１２８上で不正に実行される、ウイルスあるいはトロイの木馬のような不当なコードは、認証局１１０のサーバプラットフォーム１０６と宛先のトークン１３０との間で転送されるデータを破損するか、置換するか、あるいはインターセプトすることができる。
【００２６】
図２は本発明のトークン１３０を取得するための過程の実施例の流れ図である。先に説明されたように、トークン１３０は、限定はしないが、ＰＫＩ証明書／私用鍵を格納し、かつ利用することができるスマートカードあるいは他の装置の場合がある。処理は動作２００において開始し、直ちに動作２１０に進む。動作２１０では、トークン１３０が、公開鍵および私用鍵と、暗号化証明書／私用鍵と、署名証明書と、ロール証明書とを含むことができる証明書／私用鍵をラップするために用いられる固有鍵を書き込まれる。証明書／私用鍵のこのラップ処理は、トークン１３０内に含まれる全てのフィールドを暗号化し、それにより関連するパスフレーズを持たない個人からそのフィールドを保護する役割を果たす。その後、処理は動作２２０に進み、動作２１０において生成される鍵ペアの秘密／私用鍵がトークン１３０に格納される。図３および図４を参照して以下にさらに詳細に説明されるように、このように上記のラップ用鍵を用いて証明書／私用鍵をラップすることにより、トークン１３０を利用し、かつ更新するために、ユーザがセキュアなコンピュータシステムを利用する必要はない。動作２３０では、ユーザのアイデンティティおよびクレデンシャル（信用証明書）が個人登録局１４６によって検証される。この個人登録局１４６はバッジあるいはセキュリティ担当者の場合がある。その後、個人登録局１４６は、ユーザ同一性確認（本人確認）、トークン同一性確認および組織コードを含む電子書式での要求に署名する。トークン同一性確認は製造過程において各トークンに埋め込まれる一意の識別子である。この情報は認証局１１０に送信される。動作２５０では、認証局１１０がこのユーザに割り当てられた重複するトークン１３０を検査し、それを失効させる。動作２６０では、認証局１１０によって、ユーザの組織のデータベースから電子書式が記入される。動作２７０では、個人登録局１４６が、ユーザ１３２によって供給されるクレデンシャルに対するデータを審査した後、電子書式に署名し、提出する。その後、処理は動作２８０に進み、認証局１１０が個人登録局１４６の署名証明書の有効性を検証する。動作２８０は、個人登録局１４６のアイデンティティを検証し、許可されない個人によってトークンが発行されるのを防ぐための役割を果たす。その後、処理は動作２９０に進み、認証局１１０によって全ての暗号化、署名およびロール証明書が生成され、トークン１３０の公開鍵にラップされる。このラップ機能は、許可されない個人によるインターセプトを防ぐために、証明書／私用鍵を暗号化するための役割を果たす。その後、動作３００では、トークン１３０が、その私用鍵を用いて、受信された証明書／私用鍵をアンラップすることができ、それにより証明書／私用鍵が有効化（活性化）される。トークン１３０だけが公開鍵と一致する私用鍵を有し、証明書／私用鍵を開き、それらを有効化することができる。さらに、証明書／私用鍵を開くことを試みる前に、トークン１３０によってパスフレーズが要求される場合がある。その後、処理は動作３１０に進み、終了する。
【００２７】
図３は、本発明の実施例においてトークン１３０に収容される証明書／私用鍵を暗号化するために用いられる公開鍵／私用鍵のペアを生成するために用いられる過程を示すモジュール構成図である。図２を参照して先に説明されたように、認証局１１０はトークン１３０を生成するための要求を受け取るであろう。その際、認証局１１０は鍵生成登録局３２０にアクセスし、トークン１３０によって要求される公開鍵／私用鍵ペアを生成するであろう。鍵生成登録局３２０は暗号アクセラレータ３３０にアクセスし、公開鍵／私用鍵ペアを生成するであろう。一旦、公開鍵／私用鍵ペアが生成されたなら、この鍵ペアはトークン個別化（パーソナライゼーション）システム３４０に送信され、そこで信頼すべきデータベース１０４の必要なレコードが生成されるであろう。このレコードは、トークン１３０の製造業者によって生成されるトークンＩＤと、ユーザＩＤと、トークン１３０が含む全ての暗号化、署名、およびロール証明書／私用鍵とを含むであろう。その後、私用鍵／公開鍵がトークンにダウンロードされるであろう。その後ある時点で、信頼すべきデータベースに格納される公開鍵を用いて全ての証明書／私用鍵が符号化され、ダウンロードパケットとしてトークン１３０にダウンロードされるであろう。
【００２８】
図４は、ユーザ１３２を確証し、証明書を作成し、公開鍵内に証明書をラップ／暗号化し、かつトークン１３０に格納される私用鍵を用いて証明書／私用鍵を復号化するために用いられるロジックを示す流れ図である。処理はオペレーション（動作）４００において開始し、直ちに動作４１０へ進む。動作４１０において、認証局１１０のウェブページにユーザ１３２がクライアントプラットフォーム１２８を用いてアクセスする。動作４２０において、トークン１３０がクライアントプラットフォーム１２８においてトークンリーダによって読み出される。その後、動作４３０において認証局１１０は、ユーザ１３２のアイデンティティを認証するために、トークン１３０内に位置するユーザ１３２のための署名証明書にアクセスする。動作４４０において、認証局１１０はユーザ署名証明書および、製造業者によってトークン中に埋め込まれたトークンＩＤを認証する。トークンＩＤおよび、署名証明書を利用して、認証局１１０は、信頼すべきデータベース１０４にアクセスすることによってユーザ１３２を認証する。上述したように、信頼すべきデータベース１０４は、ユーザＩＤ、ユーザ１３２に関するトークンＩＤ、および各トークンＩＤに関する証明書／私用鍵を含むレコードを有する。次に処理は動作４５０に進み、ここで認証局１１０はユーザ１３２によって要求される任意の新しい証明書／私用鍵を生成する。動作４６０において、生成された鍵および証明書／私用鍵は、トークンＩＤに基づいてトークン１３０のために信頼すべきデータベース１０４から検索した公開鍵を利用してラップされる（暗号化される）。さらに、認証局は、独自の署名証明書を使用して、ラップされた証明書／私用鍵にデジタル署名をする。このようにして、ユーザ１３２は、ユーザ１３２トークン１３０が受け取ろうとしている証明書／私用鍵が認証局１１０によって実際に生成されたことを確信することができる。その後、動作４７０において、ラップおよび／署名された証明書／私用鍵は、次にクライアントプラットフォーム１２８にダウンロードされる。動作４８０において、この証明書／私用鍵はトークン１３０上にロードされ、トークン１３０に格納されている私用鍵を用いてトークン１３０によって復号化される。トークン１３０に格納されている私用鍵のみが認証局１１０から受け取った任意の証明書／私用鍵を活性化させることができることに留意されたい。その後、処理は動作４９０へ進み、処理は終了する。
【００２９】
本発明の実施形態を用いて、ユーザは、セキュアなコンピュータ、通信回線あるいはセキュリティオフィサを用いずにトークン中に証明書／私用鍵をダウンロードすることができる。これは、一意の識別番号が割り当てられ、かつトークン１３０上の読み取り専用位置上に焼き付けられてトークン１３０が製造されたと認識することによって本発明の実施形態を用いることで可能である。本発明の実施形態は各トークン１３０に対して一意の私用鍵および公開鍵を作成する。本発明の実施形態は、公開鍵基盤内の任意の他のエンドエンティティのようにトークン１３０を扱う。トークン１３０は、一意のアイデンティティを有する。本発明の実施形態は、トークン１３０のために私用鍵および公開鍵証明書を作成する。したがって、トークン１３０は任意の署名および／または暗号化データ通信の発信元かまたは行先であることができる。本発明の実施形態の前に、サーバプラットフォーム１０６およびトークン１３０から転送されたデータはサーバプラットフォーム１０６とクライアントプラットフォーム１２８の間で暗号化され、クライアントプラットフォーム１２８とトークン１３０の間で平文（暗号化されていない）として中継されることができる。本発明の実施形態の後、データはサーバプラットフォーム１０６からトークン１３０までずっと暗号化されている。クライアントプラットフォーム１２８は、復号化またはアンラップ（unwrap）することのできない暗号化されたデータを中継する。したがって、以前のセキュリティ脆弱性は存在しない。
【００３０】
本明細書においてはいくつかの例だけを図示し、記載したが、当業者には明らかなような多数の改変および変更を本発明に対して行うことができることは理解される。たとえば、本発明の実施形態に対して任意のタイプのコンピュータアーキテクチャが用いられることができる。さらに、本発明は任意の汎用のコンピュータ言語で書くことが可能である。また、証明書／私用鍵がトークンに含まれることに限定される必要はなく、パスポート、クレジットカード、運転免許証、キャッシュカードあるいは他のタイプのカードに対して用いられることが可能である。なぜなら、それらは全て、証明書／私用鍵と同じ公開鍵にラップされることによりセキュアにされることになるためである。それゆえ、本明細書において図示および記載される細部は限定するためのものではなく、特許請求の範囲によって包含されるような全てのそのような改変および変更が網羅されることを意図している。
【００３１】
上記の説明は本発明の例示的な実施例を開示し、記載しているにすぎない。当業者であれば、そのような説明ならびに添付の図面および特許請求の範囲から、併記の特許請求の範囲に定義されるような本発明の精神および範囲から逸脱することなく、種々の改変、変更および変形がなされる場合があることは容易に理解されよう。
【図面の簡単な説明】
【図１】本発明の実施形態において用いられるソフトウェア、ファームウェアおよびハードウェアのモジュール構成図である。
【図２】本発明におけるトークンを取得するためのプロセスの実施例の流れ図である。
【図３】本発明の実施例においてトークンに収容される証明書／私用鍵を暗号化するために用いられる公開鍵／私用鍵のペアを生成するために用いられる過程を示すモジュール構成図である。
【図４】ユーザ１３２を認証し、証明書を作成し、公開鍵内に証明書をラップ／暗号化し、トークン１３０に格納される私用鍵を用いて証明書を復号化するために用いられるロジックを示す流れ図である。
【図１】
0004625234.tif 000003
【図２】
0004625234.tif 000004
【図３】
0004625234.tif 000005
【図４】
0004625234.tif 000006