クライアント側証明書認証情報の認証保存方法と認証保存システム
複数のクライアント証明書認証情報をキーストアファイル内に保存する認証保存方法は、クライアントウェブブラウザ（２８）を使用することで、クライアントコンピュータ（１２）とサーバコンピュータ（１４）の間の安全なデータ転送リンクを確立する。クライアントウェブブラウザ（２８）は、キーストアファイルと鍵対を生成するプラグインコンポーネント（３０）を有する。クライアントコンピュータ（１２）上で、証明書要求を生成するステップが続く。証明書要求は、証明書サーバ（４４）に送信される。証明書サーバ（４４）は、証明書要求に電子署名する。署名証明書要求（４６）は、クライアントウェブブラウザ（２８）を介して、クライアントコンピュータ（１２）によって受信される。認証保存方法は、署名証明書要求（４６）に関連する複数のクライアント証明書認証情報を、１つ以上のキーストアファイル内に保存する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にクライアント証明書認証情報を保存するための方法とシステムに関し、更に詳細には本発明は、複数のクライアント証明書認証情報を、クライアントウェブブラウザを介してキーストアファイル内に自動的にクライアントセルフサービス保管するための方法とシステムに関する。
【背景技術】
【０００２】
公開鍵基盤（ＰＫＩ）は、事前の接触なしにコンピュータ間で互いに認証できるようにするとともに、それらの公開鍵証明書内の公開鍵情報を使用して互いに対するメッセージを暗号化できるようにする。一般に、公開鍵基盤は、クライアントソフトウェア、サーバソフトウェア、ハードウェア、および運用手順で構成されている。公開鍵基盤は、インターネットによる安全通信に関連する非常に重要な役割を果たしている。銀行業務、金融サービス、行政、教育、およびすべての種類の企業は、最新式コンピュータシステムとインターネットのようなデータ通信ネットワークとに依存している。このような進歩は、商取引を行う速度と利便性とを大幅に向上させてきたが、多くの脆弱性のために、やりとりされている機密性と極秘性の高いデータの安全性が危険にさらされている。最も基本的なレベルにおいて、電子商取引は、ネットワークを介して通信するサーバコンピュータシステムとクライアントコンピュータシステムとを通常有する。また付加的なクライアントまたはサーバコンピュータシステムをネットワークに接続して、複数のクライアントが所与のサーバにアクセスできたり、または所与のクライアントが複数のサーバにアクセスできたりするようになっていてもよい。このオープンネットワーク環境では、データ機密保護について３つの主要な懸案事項がある。まず第１に、クライアントは、それ自身が主張する通りのものであるということをサーバに対して保証しなければならない。第２に、サーバは、それ自身が主張する通りのものであるということをクライアントに対して保証しなければならない。第３に、正当なサーバと正当なクライアントの間でやりとりされている任意の情報は、ネットワーク上の他のいかなるコンピュータシステムまたは使用者によっても妨害されたり、または変更されたりしてはいけない。
【０００３】
たとえばエレクトロニックバンキングセッティングでは、銀行は、銀行用サーバにアクセスする使用者の身元を認証して、特定の顧客だけに関連する取引が許可されるようになっているとともに、銀行用サーバにアクセスする使用者が、その特定の顧客か、またはその特定の顧客が権限を与えた人であると確認されるようになっていなければならない。銀行用サーバが本当に銀行によって運用されている銀行用サーバであり、悪意があるエンティティによって運用されている類似の銀行用サーバではないことをクライアントに確保しなければならない。これはフィッシング攻撃として知られており、正当なサーバに似せて偽装サーバを作り、使用者をだまして銀行口座番号、社会保障番号、パスワード、およびその種の他のものなどの秘密情報を提供させるものである。負債の誤った累算、逮捕歴、刑事上の有罪判決、取引信用度の破壊、評判の棄損などを有する情報を有する犯罪者が、多くの損害を顧客に与える虞がある。またこれらは、「なりすまし犯罪」としても知られている。秘密情報がオープンネットワークを介して伝送されているため、このような情報は、暗号化されるか、さもなければクライアントとサーバ以外には、他のいかなるシステムにも分からないようにされる必要がある。ネットワークのオープン性によって、不正目的または悪意のある目的のために有効データ伝送を傍受して後で繰り返すリプレイアタックをコンピュータシステムが受けやすくなる。たとえばパスワードまたは他の認証情報が傍受されて、後で機密情報にアクセスするために使用される。更にネットワーク上で伝送されている情報は、介入者攻撃の場合などに変更可能であってはならない。これは、リンクが危険にさらされやすいことを正当なクライアントとサーバのどちらも認識することな
く、両者の間のデータを攻撃者が読み取り、挿入して、変更することを有する。
【０００４】
一般に、これらのセキュリティ問題は、機密データおよび／または極秘データをやりとりしているすべてのネットワーク環境において最重要課題である。多くの企業では、インターネットなどの公衆通信ネットワークを介して組織の内部ネットワーク資源に安全に遠隔アクセスするために、仮想専用ネットワーク（ＶＰＮ）を現在のところ利用している。上述した攻撃を防ぐ適切な防護対策が施されなければ、組織のデータのセキュリティも、組織の顧客のデータまたはクライアントのデータのセキュリティも危険にさらされて、１人の個人だけに与える損失よりも更に大きな損失をもたらす虞がある。
【０００５】
一般に、公開鍵暗号は、受け手と送り手の両方が保持する固有の公開鍵／秘密鍵対を有する。送り手の秘密鍵は、送り手だけで保持されており、受け手の秘密鍵は、受け手だけで保持されている。送り手の公開鍵は、配布されて、受け手によって保持され、受け手の公開鍵もまた配布されて、送り手によって保持される。メッセージを送信するときには、送り手の秘密鍵と受け手の公開鍵を使用してメッセージを暗号化する。メッセージは、受け手の秘密鍵と送り手の公開鍵とを用いて受け手によって解読される。
【０００６】
電子証明書は、信頼できる結びつきでクライアントの身元証明書とクライアントの公開鍵を関連付けるコンピュータで作成した記録である。信頼は、第三者の認証機関によって実施される登録証明書／身元証明書ポリシーに基づいている。証明書は、認証を発行する認証機関の身元証明書、クライアント、クライアントの公開鍵を有してもよく、証明書は、発行認証機関によって電子署名される。電子署名は、１つの装置を他の装置に対して認証するために使用される一般的な方法である。証明書は、電子署名と公開鍵暗号方式とで要求される鍵配布機構を提供する。電子署名を使用するために、署名を提供している装置上に個人情報（秘密鍵）を保存しなければならない。保存された個人情報は、秘密鍵を有するハードウェアデバイスを盗んだ攻撃者を助ける虞があり、たとえば攻撃者は、ルータ内に保存されたＲＳＡ秘密鍵を使用することによってルータに他のサイトへの安全な接続を開始させることができるかもしれない。
【０００７】
暗号作成法において周知の証明書規格は、Ｘ．５０９証明書である。証明書の構造は、バージョン、通し番号、アルゴリズムＩＤ、発行、有効期間、対象者、対象者の公開鍵情報、発行者の一意的識別子、対象者の一意的識別子、拡張、証明書署名アルゴリズム、および証明書署名を有してもよい。証明書は、国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）勧告であり、「ディレクトリ」で表される中央制御パラダイムに基づき認証サービスの規定の枠組みを定めている。勧告は、要求された身元の検証としてパスワードを使用する簡易認証と、暗号技術を使用することによって形成された認証情報、すなわち「証明書」を有する厳密認証と、の２つのレベルについて記述している。信頼を確立して維持することに関して認証機関の責任といっしょに証明書構造の形式を定めている。
【０００８】
Ｘ．５０９規格のような証明書、証明書チェーン、および秘密鍵は、キーストアファイルとして知られているものに保存される。通常、キーストアファイルは、ファイルの中に保存された情報を保護するために暗号化されている。キーストアファイル内に保存された情報は、上述のセキュリティ問題のため秘密になっている。キーストアファイルには、２つのパスワードを用いてアクセスしてもよい。１つのパスワードは、キーストアファイルへのアクセスを提供し、別の第２パスワードは、キーストアファイルの中に保存された秘密鍵へのアクセスを提供する。保護されたキーストアファイルのために開発された幾つかの規格がある。最も一般に普及しているのは、ＰＫＣＳ＃１２規格である。ＰＫＣＳ＃１２の規格は、付随の公開鍵証明書を備え、パスワードベースの対称鍵で保護された秘密鍵を保存するために一般的に使用されるファイル形式で定められたキーストアを提供する。これは、一例として複数の証明書を有する複数の埋め込みオブジェクトを有することがで
きるコンテナフォーマットである。この標準形式は、ＪＡＶＡ（登録商標）キーストアとともに使用してもよい。認証機関がクライアントに電子証明書を発行するとき、クライアントは、保護されたキーストアファイルを最終的に受取り、この保護されたキーストアファイルは、発行された証明書と、その証明書に対応する秘密鍵と、全体の証明書チェーンと、を含んでおり、証明書の信頼性を提供している。保護されたキーストアファイルは、クライアントにファイルの形でスマートカードとして渡してもよく、またはクライアントおよび／もしくはクライアントのウェブブラウザに直接インストールしてもよい。
【０００９】
最終の使用者の正当性を確保する形でインターネット全体にわたって認証するための実証された方法は、公開鍵／秘密鍵対を使用して認証要求に電子署名することである。このシナリオでは、使用者の秘密鍵を使ってメッセージに署名することによってクライアントがその身元を立証するであろうということを期待して、認証サーバがクライアントにメッセージを送信する。ほとんどの場合、このメッセージは、ＭＤ２、ＭＤ４、ＭＤ５、ＳＨＡ１または他の何らかのハッシュアルゴリズムなどの何らかの一般的なハッシュ機構を利用してデジタル処理でハッシュ化されたメッセージである。クライアントは、ハッシュを実行し、その後、使用者の秘密鍵を使ってこのハッシュに署名して、この電子署名されたメッセージをサーバに戻す。その後、サーバは、同じハッシュアルゴリズムを利用して同じメッセージをデジタル処理でハッシュして、この値を後で比較するために保存し、このハッシュ値は、「現在のハッシュ値」と呼ばれる。その後、サーバは、電子署名された署名をクライアントから受取り、使用者の公開鍵を使ってこのハッシュ値を解読する。その後、サーバは、この解読された電子署名と現在のハッシュ値を比較し、この２つが同じではない場合、その電子署名は、無効であり、検証は、失敗となる。発行手続きにおいてクライアントのウェブブラウザが役立つ可能性がある。
【００１０】
サーバまたはウェブサイトから所与の認証機関に送信した証明書発行要求（証明書要求）において、クライアントのウェブブラウザは、公開鍵／秘密鍵対を生成してもよく、認証機関のサーバにその公開鍵を送信する。クライアントウェブブラウザは、秘密鍵を秘密にしておき、認証機関には、秘密鍵を送信しない。認証機関は、クライアントの個人の身元データの信頼性を検証した後に、クライアントのウェブブラウザが受信した公開鍵とクライアントの確認された身元データとを記録している証明書をクライアントに発行する。認証機関のサーバがそのクライアントに証明書を発行した後に、認証機関は、証明書をクライアントのウェブブラウザ内にインストールすることができるウェブページにクライアントをリダイレクトする。ウェブブラウザは、証明書に対応する秘密鍵を保存しており、最後には、使用者は、証明書の、クライアントのウェブブラウザ内にインストールされた証明書チェーンとともに、証明書とそれに対応する秘密鍵とを入手する。秘密鍵を保存する方法は、ウェブブラウザに応じて一般に変化する。
【００１１】
ほとんどのクライアントウェブブラウザは、認証用に安全なＳＳＬサーバの中に保存された証明書と秘密鍵とを使用することができる。また多くのＥ−ｍａｉｌクライアントは、クライアントウェブブラウザ内に保存された証明書を使用して、電子メールに署名し、暗号化し、解読することもできる。しかし、幾つかのアプリケーションは、クライアントのウェブブラウザからの証明書を直接使用することはできないが、特定のキーストアファイルとともに動作できる。このような場合には、クライアントの使用者は、それらのクライアントウェブブラウザからのそれらの証明書を、キーストアファイル内のそれらの証明書に対応する秘密鍵といっしょにエクスポートして、他の任意のアプリケーションでそれらを使用してもよい。Ｘ．５０９電子証明書を保存するための幾つかの規格がある。ＡＳＮ．１ ＤＥＲ符号化が最もよく使用され、この符号化では、証明書は、．ＣＥＲ拡張子を有するファイル内に保存される。．ＣＥＲファイルは、公開鍵と、その公開鍵の所有者の情報と、その公開鍵が本当にその使用者またはクライアントに帰属することを証明する認証機関の電子署名と、を有する。認証機関は、認証機関のサイトから、．ＣＥＲファイ
ル内の認証機関のルート証明書を配布する。．ＣＥＲファイルは、バイナリ形式またはＢａｓｅ６４で符号化されたテキスト形式で保存できる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許出願公開第２００４／２６８１４８号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、多くのキーストアファイルアプリケーションは、認証機構とは無関係である。これらのキーストアファイルアプリケーションは、複数の記憶領域内の公開鍵／秘密鍵を検索して利用する。これらの第三者製のアプリケーションは、公開鍵／秘密鍵、または他のキーストアファイルロケーション内の他の証明書認証情報を通常検索できない。あるいは第三社製のアプリケーションは、アプリケーションが書き直された後にだけ、他のキーストアファイルロケーション内の複数のクライアント証明書認証情報を検索してもよい。通常そのアプリケーションでは、検索するように設計されていないキーストアファイルロケーションを検索するように、サードパーティ製アプリケーションを書き直すことは困難であり、クライアントコンピュータのほとんどの使用者には、推奨できない。
【００１４】
よくある問題は、アプリケーションが、ＪＡＶＡ（登録商標）キーストア内に保存される予定の複数のクライアント証明書認証情報を探す点である。ほとんどの認証ソリューションでは、ブラウザ専用のキーストアファイル内に複数のクライアント証明書認証情報を保存しているため、アプリケーションは、認証情報を見つけることができず、その結果、使用者を認証しない虞があり、従ってアプリケーションが役に立たなくなる。この問題に対する過去の解決方法は、使用者が手動で証明書情報を抽出して他のキーストアファイル内に複製することであった。しかし上述したように、これは間違いを犯しやすい困難な手順であり、ほとんどの使用者の技術能力を超えてしまう。
【課題を解決するための手段】
【００１５】
よって当技術分野において、１つのキーストアファイルまたは複数のキーストアファイルの中にクライアント証明書認証情報を保存するための改良された方法とシステムに対する必要性が存在している。
【００１６】
本発明の一実施形態に基づき、クライアントウェブブラウザを介してキーストアファイルに複数のクライアント証明書認証情報を保存するための方法を提供する。方法は、クライアントとサーバの間の安全なデータ転送リンクを確立するステップで始まる。クライアントウェブブラウザを使用してクライアントとサーバの間の安全なデータ転送リンクを確立する。クライアントウェブブラウザは、プラグインソフトウェアコンポーネントを有する。プラグインソフトウェアコンポーネントは、クライアントとサーバの間に安全なデータ転送リンクを確立するプロセスの間に、キーストアファイルと、公開鍵と秘密鍵とを有する鍵対と、を生成するように構成されている。方法は、クライアント上で証明書要求を生成するステップを続けてもよい。生成された証明書要求は、プラグインソフトウェアコンポーネントによって生成された鍵対からクライアントウェブブラウザへの公開鍵を有する。その後、生成された証明書要求を証明書サーバに送信する。証明書サーバは、生成された証明書要求に電子署名するように構成されている。方法は、署名証明書要求をクライアントが受信するステップを続ける。署名証明書要求は、クライアントウェブブラウザを介してクライアントによって受信される。方法は、署名証明書要求に関連する複数のクライアント証明書認証情報をキーストアファイル内に保存するステップで終わってもよい。
【００１７】
本発明の他の実施形態に基づき、複数のクライアント証明書認証情報は、電子証明書、
秘密鍵、公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する。本発明の他の態様では、クライアントとサーバの間の安全なデータ転送リンクを確立するステップは、サーバを用いた多元的認証過程の完了を成功させるようにクライアントに要求する。またプラグインソフトウェアコンポーネントがサーバからクライアントウェブブラウザに送信されたブラウザ実行コードであることを想定する。プラグインソフトウェアコンポーネントは、複数のキーストアファイルを生成するように構成されていてもよい。プラグインソフトウェアコンポーネントは、複数のクライアント証明書認証情報を選択的に保存してもよい。プラグインソフトウェアコンポーネントによって選択的に保存される予定の複数のクライアント証明書認証情報は、署名証明書要求に関連している。複数のクライアント証明書認証情報は、プラグインソフトウェアコンポーネントによって生成された複数のキーストアファイル内に保存してもよい。また方法は、サーバがセキュアソケットレイヤ（ＳＳＬ）仮想専用ネットワーク（ＶＰＮ）であることを想定する。また証明書サーバがクライアントとサーバとから遠く離れた認証機関であることを想定する。複数のクライアント証明書認証情報を保存するために選択される予定のキーストアファイルは、マイクロソフト暗号ＡＰＩキーストアと、ＪＡＶＡ（登録商標）キーストアと、アップルキーストアと、ＮＳＳキーストアと、からなる群から選択されてもよい。しかし、上述のキーストアの種類は、あくまで実施例を示したに過ぎず、本発明は、実施例としてここに示していない付加的なキーストアを利用することを想定する。プラグインソフトウェアコンポーネントは、クライアントウェブブラウザを確認して、クライアントウェブブラウザの符号化ライブラリに関連するキーストアファイル内に複数のクライアント証明書認証情報を保存してもよい。
【００１８】
本発明の更に他の実施形態では、複数のクライアント証明書認証情報を保存するためのシステムを提供する。システムは、クライアントとサーバの間の安全なデータ転送リンクを確立するためにクライアント上にクライアントウェブブラウザを有する。またシステムは、複数のキーストアファイルを有する。複数のキーストアファイルは、クライアントウェブブラウザによって生成される。またシステムは、証明書サーバを有してもよい。証明書サーバは、クライアントによって生成された証明書要求を受信できる。証明書サーバは、証明書要求に電子署名するように構成されている。システムは、プラグインソフトウェアコンポーネントを有する。プラグインソフトウェアコンポーネントは、クライアントウェブブラウザへのアドオンである。クライアントウェブブラウザは、プラグインソフトウェアコンポーネントを処理して公開鍵と秘密鍵とを有する鍵対を生成する。またプラグインソフトウェアコンポーネントは、複数のクライアント証明書認証情報を選択的に保存するように構成されている。本発明の態様は、プラグインソフトウェアコンポーネントが複数のキーストアファイルから少なくとも１つのキーストアファイル内に複数のクライアント証明書認証情報を保存することを想定する。本発明の他の実施形態では、プラグインソフトウェアコンポーネントは、複数のキーストアファイル内に複数のクライアント証明書認証情報を保存する。
【００１９】
またキーストアファイル内に選択的に保存される予定の複数のクライアント証明書認証情報は、電子証明書、クライアント秘密鍵、クライアント公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有することを想定する。システムのクライアントウェブブラウザは、サーバを用いた多元的認証過程の完了に成功することによって、安全なデータ転送リンクを確立する。システム内に含まれる証明書サーバは、クライアントとサーバとから遠く離れた認証機関である。本発明の他の実施形態では、証明書サーバは、サーバでホストされている。システムのクライアントウェブブラウザは、電子証明書を生成するように構成されている。電子証明書は、署名証明書要求の受信に呼応して通常生成される。電子証明書は、証明書サーバによって検証された情報を有するであろう。システムのプラグインソフトウェアコンポーネントは、サーバからクライアントウェブブラウザに送信されたブラウザ実行コードである。本発明の他の実施形態では、プラグインソフトウ
ェアコンポーネントは、サーバから独立しているクライアント上のインストール過程を通してクライアントウェブブラウザに付加されたブラウザ実行コードである。
【００２０】
同じ要素を示すために図面と詳細な説明の全体を通して共通の参照番号を使用している。
本発明は、添付図面とともに以下の詳細な説明を参照することによって、最も良く理解されるであろう。
【００２１】
本明細書で開示したさまざまな実施形態の、これらのおよび他の特徴、ならびに利点は、以下の説明と図面を参照することによって、より良く理解されるであろう。
添付図面に関連して以下に示す詳細な説明は、本発明の現在の好ましい実施形態を説明するものであり、本発明を構成したり、または利用したりしてもよい唯一の形態を示すものではない。説明は、図示の実施形態に関連して本発明を開発して運用するためのステップの機能と順序を示している。しかし、それもまた有するように意図されている互いに異なる実施形態によって、同じまたは等価な機能と順序を達成してもよいことを理解すべきである。当然のことながら、第１と第２の、ならびにその種の他のものなどの関係用語の使用は、１つのエンティティと他のエンティティを区別するためにだけ使用されており、このようなエンティティの間の実際のこのような関係または順序を必ずしも要求したり、または示唆したりするわけではない。
【図面の簡単な説明】
【００２２】
【図１】本発明の一態様が実現可能な環境を示すブロック図。さまざまな相互接続されたサーバ、クライアント、および仮想専用ネットワーク（ＶＰＮ）を有する。
【図２】本発明の態様の複数のクライアント証明書認証情報を保存するための方法を示すフローチャート。
【図３】サーバに対するクライアントの認証に呼応して、クライアント証明書認証情報を保存するための第１例示的構成。
【図４】本発明の一態様が実現可能な環境を示す第２例示的構成。
【発明を実施するための形態】
【００２３】
図１を参照すると、例示的なコンピュータネットワーク１０は、さまざまなデータ処理装置またはコンピュータとしてのクライアントコンピュータ１２と、サーバコンピュータ１４とを有する。更に詳細には、クライアントコンピュータ１２は、クライアントとして機能するパーソナルコンピュータまたはワークステーションであってもよく、中央演算処理装置と、記憶デバイスと、その種の他のものとを内蔵するシステム装置１６を有してもよい。またクライアントコンピュータ１２は、表示装置１８と、キーボード２０ａおよびマウス２０ｂのような入力装置２０と、を有してもよい。システム装置１６は、中央演算処理装置で現在実行中の前もってプログラムされた命令の制御とフローとを変更するさまざまな入力を入力装置２０から受信し、このような実行処理の結果を表示装置１８上に示すことが分かる。サーバコンピュータ１４は、クライアントコンピュータ１２にデータまたはサービスを提供するサーバであってもよい。この点について、用語「クライアント」は、データまたはサービスのリクエスタとしてのクライアントコンピュータ１２の役割を指していると理解され、他方、用語「サーバ」は、このようなデータまたはサービスを提供するサーバコンピュータ１４の役割を指していると理解される。更にクライアントコンピュータ１２は、１つのトランザクション内でデータまたはサービスを要求してもよく、トランザクション内でデータまたはサービスを提供してもよく、このように、その役割をクライアントからサーバに、またはその逆に変えることができる。また更に当然のことながら、本明細書で利用されているような用語「サーバ」は、一般に、セキュアソケットレイヤ／トランスポートレイヤセキュリティ（ＳＳＬ／ＴＬＳ）仮想専用ネットワーク（ＶＰＮ）などのネットワークサービスを指してもよく、このネットワークサービスを通じて
、従来のサーバコンピュータ１４は、リモートクライアントにデータとソフトウェアアプリケーションを提供する。
【００２４】
クライアントコンピュータ１２とサーバコンピュータ１４は、ネットワーク接続２４を介してインターネット２２などの広域ネットワークに接続されている。クライアントコンピュータ１２からの要求と、サーバコンピュータ１４から要求されたデータとは、ネットワーク接続２４を介して配信される。本発明の実施形態に基づき、サーバコンピュータ１４は、ウェブサーバであり、クライアントコンピュータ１２は、サーバコンピュータ１４によって提供された資料を表示装置１８上に視覚的に描画するマイクロソフト社のインターネットエクスプローラのようなウェブ閲覧アプリケーションを有してもよい。当然のことながら、図１に示したネットワークトポロジは、限定としてではなく、あくまで一例を示したに過ぎず、本発明の範囲を逸脱することなく、他の任意の種類のローカルエリアネットワークまたは広域エリアネットワークを容易に代わりとして使用してもよい。ネットワーク接続２４とインターネット２２に対して、周知の任意のデータ転送プロトコルを利用してもよいことが分かる。
【００２５】
さらなる実施例では、第１サーバコンピュータ１４ａは、課金情報と資金移動機能を提供するエレクトロニックバンキングウェブサーバであってもよい。また付加的な使用法も想定され、その使用法では、第１サーバコンピュータ１４ａは、メールサーバ、オンラインショッピングサイト、またはマイクロソフト社の．ＮＥＴアプリケーションをホスティングする。第１クライアントコンピュータ１２ａの使用者は、第１サーバコンピュータ１４ａにログオンして、クライアントウェブブラウザを用いて勘定残高を読み出し、資金を別の口座に移動させてもよい。この例示的状況では、情報セキュリティの問題の１つは、第１クライアントコンピュータ１２ａの使用者が、彼がそうであると主張する人本人であることを確保することを有する。たとえば第２クライアントコンピュータ１２ｂの悪意のある使用者が、第１クライアントコンピュータ１２ａの使用者の認証情報のすべてを有しており、このようなアクセスが不正であると認識せずに第１サーバコンピュータ１４ａにログオンする虞がある。他の問題は、第１サーバコンピュータ１４ａが銀行の管理下にあり、第１クライアントコンピュータ１２ａの使用者がその銀行の顧客であることを確保することである。フィッシング攻撃で第２サーバコンピュータ１４ｂが第１サーバコンピュータ１４ａになりすましている虞があるかもしれず、第１クライアントコンピュータ１２ａが、間違って第２サーバコンピュータ１４ｂにアクセスしてしまう虞がある。更に第１クライアントコンピュータ１２ａと第１サーバコンピュータ１４ａの間のすべての正当なデータ転送は、第３クライアントコンピュータ１２ｃと、第２クライアントコンピュータ１２ｂと、第２サーバコンピュータ１４ｂとを有する他のいかなるコンピュータによっても傍受されてはならない。
【００２６】
上述したように、特定の第１サーバコンピュータ１４ａにアクセスする代わりに、クライアントコンピュータ１２は、仮想専用ネットワーク（ＶＰＮ）１５にアクセスしてもよい。仮想専用ネットワーク１５は、仮想専用ネットワークルータ１７を介してインターネット２２に接続され、クライアントコンピュータ１２への遠隔アクセスを可能にしてもよい。仮想専用ネットワークルータ１７は、外部のクライアントコンピュータ１２がローカルネットワーク１９上の仮想サーバコンピュータ１４ｃにアクセスできる唯一の様態であることが分かる。上述したのと同じ安全上の懸念が仮想専用ネットワーク１５にも同様に適用できるため、更に詳細に後述するように本発明の方法とシステムを実現する可能性があると想定される。
【００２７】
図２のフローチャートを参照すると、図は、複数のクライアント証明書認証情報をキーストアファイル内に選択的に保存するためのさまざまなステップを示している。キーストアファイルは、鍵対のインメモリコレクションと、電子証明書と、他のクライアント証明
書認証情報とである。たとえばキーストアファイルは、機密性の高い暗号鍵情報を保持していてもよく、この暗号鍵情報は、不正アクセスを防ぐために保護フォーマット内に保存されている。通常、この種類のエントリ内に保存される認証情報は、対応する公開鍵に対する証明書チェーンをともなう秘密鍵である。秘密鍵と証明書チェーンは、自己認証を行うために所与のエンティティによって使用される。信頼できる証明書エントリは、他の当事者に属する単一の公開鍵証明書を有する。その単一の公開鍵証明書は、証明書内の公開鍵が証明書の対象者（所有者）によって確認された身元に帰属していることをキーストアファイル所有者が信じるため、信頼できる証明書と呼ばれる。証明書キーストアファイルに対する登録プロセスは、専用のクライアントソフトおよび／または手動の管理者起動プロセスに通常基づいている。更にこのプロセスは、クライアントコンピュータ１２の使用者に任せてもよい。しかし、暗号化されたキーストアファイルのセキュリティは、多元的認証に基づいてもよい。
【００２８】
特に、図２に開示したフローチャートの第１ステップＳ１００は、クライアントコンピュータ１２とサーバコンピュータ１４の間の安全なデータ転送リンクを確立することを想定する。本発明の一実施形態では、クライアントコンピュータ１２をサーバコンピュータ１４に対して認証するのに成功した後にだけ、安全なデータ転送リンクが確立されることを想定する。サーバコンピュータ１４に対してクライアントコンピュータ１２を認証する過程は、多元的認証を有する。ここで図３を参照すると、クライアントの多元的認証過程を示している。サーバコンピュータ１４を用いてクライアントコンピュータ１２を登録して多元的認証過程を完了するのに成功することで、クライアントコンピュータ１２が詐欺師またはハッカーではないことを確保するとともにクライアントコンピュータ１２とサーバコンピュータ１４の間のすべての通信を保護することによって、クライアントコンピュータ１２とサーバコンピュータ１４の間の安全なデータ転送リンクを確立してもよい。クライアントコンピュータ１２の使用者２６は、サーバコンピュータ１４を用いて安全ではない接続を確立することによって、登録と認証過程を開始してもよい。たとえば使用者２６は、クライアントコンピュータ１２上のクライアントウェブブラウザ２８つまりクライアントブラウザに、サーバコンピュータ１４に関連するネットワークアドレスを入力してもよく、その時点でサーバコンピュータ１４上のファイルまたはウェブページに対する要求が出される。それに呼応して、サーバコンピュータ１４は、クライアントコンピュータ１２の使用者２６がサーバコンピュータ１４にアクセスする権限を与えられているか否か判断するための情報を要求してもよい。
【００２９】
クライアントコンピュータ１２とサーバコンピュータ１４の間で想定される相互作用は、クライアントコンピュータ１２がクライアントウェブブラウザ２８を介してサーバコンピュータ１４にログオンすることを有してもよい。要求される情報は、たとえばユーザ名またはパスワードを有してもよい。その後、クライアントコンピュータ１２上のクライアントウェブブラウザ２８は、使用者２６に、サーバコンピュータ１４にアクセスするためのユーザ名および／またはパスワードの入力を要求する。その後、サーバコンピュータ１４は、クライアントコンピュータ１２の使用者２６が提供した情報が正しいか否か判断してもよい。サーバコンピュータ１４は、サーバソフトウェアアプリケーション３４を介して企業データベース３６に通信してもよく、この企業データベース３６は、バックエンドデータストアの役割を果たしてもよい。企業データベース３６は、使用者２６が正しい身元確認情報を提供したか否か判断するために、使用者２６のユーザ名とパスワードを有してもよい。本発明の一実施形態では、企業データベース３６は、サーバコンピュータ１４によってホストされている。他の実施形態では、企業データベース３６は、ネットワーク接続２４またはインターネット２２を介してサーバソフトウェアアプリケーション３４に通信するリモートサーバである。サーバコンピュータ１４は、アクティブディレクトリサーバ、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）サーバ、データベースサーバなどであってもよい。サーバソフトウェアアプリケーション３４は、サーバコン
ピュータ１４によってホストされている。サーバソフトウェアアプリケーション３４は、クライアントウェブブラウザ２８に通信すること、従ってクライアントコンピュータ１２に通信することを想定している。
【００３０】
クライアントコンピュータ１２の認証に成功する前に、帯域外の様態を介してクライアントコンピュータ１２とそれに関連する使用者２６を認証できる。一実施形態に基づき、サーバソフトウェアアプリケーション３４は、使用者２６の管理下にある携帯電話または有線電話に使い捨てパスワードを配信するように電話サーバ３８に通知する。あるいは、テキストメッセージサーバ４０から電子メールまたはショートメッセージサービス（ＳＭＳ）テキストメッセージを送信してもよい。音声認識、ＩＰアドレス検証、およびその種の他のものなどの他の帯域外認証技術が想定される。使い捨てパスワードのエントリは、サーバコンピュータ１４を通してサーバソフトウェアアプリケーション３４を用いて処理してもよい。上述の帯域外認証の代わりに、または上述の帯域外認証に加えて、付加的な知識ベース認証方式を使用者２６に提示してもよい。たとえば使用者２６に、彼らの好みの色、彼らの母親の旧姓、および他の同様の質問を尋ねてもよい。サーバソフトウェアアプリケーション３４を用いて後で読み出して使用するために、付加的な認証情報を企業データベース３６内に保存してもよい。上述の手続きは、サーバコンピュータ１４を用いてクライアントコンピュータ１２上のクライアントウェブブラウザ２８を「登録」して、このようなクライアントウェブブラウザ２８を効果的に第２認証要素（「使用者が有している何か」）にすることが分かる。上述したように、使い捨てパスワードは、クライアントコンピュータ１２とサーバコンピュータ１４の間のデータ通信リンクとは無関係な、またはクライアントコンピュータ１２とサーバコンピュータ１４の間のデータ通信リンクに関して帯域外の、通信様態を介して配信される。電話サーバ３８は、第三者、またはサーバコンピュータ１４もしくは企業データベース３６を管理する組織、が管理してもよい。サーバソフトウェアアプリケーション３４は、クライアントコンピュータ１２の使用者２６に正式な応答を入力するように指示する。この線に沿って、電話サーバ３８と、クライアントコンピュータ１２に正式な応答を送信するステップとは、省略してもよいことが分かり、ここで「正式な応答」とは、知識ベースの質問に対する回答である。この回答は、その時以前に使用者２６が決めたものと想定される。
【００３１】
多元的認証過程を通して安全なデータ転送リンクを確立した後で、図２のフローチャートの次のステップＳ１１０は、複数のクライアント証明書認証情報を生成することを有する。複数のクライアント証明書認証情報は、公開鍵と秘密鍵とで構成された鍵対を有してもよい。またこのステップは、複数のクライアント証明書認証情報を保存するためのキーストアファイルを生成することを想定する。再び図３を参照すると、クライアント装置としてのクライアントコンピュータ１２上のクライアントウェブブラウザ２８は、安全なデータ転送リンクの確立に呼応してキーストアファイルと鍵対とを生成するプラグインソフトウェアコンポーネントとしてのプラグインコンポーネント３０を有する。本発明の態様では、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４を用いた認証が成功した後に、プラグインコンポーネント３０が鍵対を生成することを想定する。本発明の一実施形態では、プラグインコンポーネント３０は、クライアントウェブブラウザ２８へのアドオンとして実現されるブラウザ実行コードである。安全なデータ転送リンクを確立した後に、プラグインコンポーネント３０をサーバコンピュータ１４から送信してもよい。また安全なデータ転送リンクを確立する前に、プラグインコンポーネント３０をクライアントウェブブラウザ２８に送信してもよいことが想定される。更にプラグインコンポーネント３０を有するブラウザ実行コードを、クライアントコンピュータ１２上に、従ってサーバコンピュータ１４とは無関係にクライアントウェブブラウザ２８上に、インストールしてもよい。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、クライアントコンピュータ１２上で処理されて、１つのキーストアファイルまたは複数のキーストアファイルを生成する。またクライアントコンピュータ１２上
でのプラグインコンポーネント３０の処理によって、サーバコンピュータ１４を用いたクライアントコンピュータ１２の認証の成功に呼応して、鍵対を生成してもよい。
【００３２】
一実施形態に基づき、プラグインコンポーネント３０は、クライアントウェブブラウザ２８を介してシングルユーザ２６インタラクションを用いてインストールされるＡｃｔｉｖｅ−Ｘコンポーネントである。しかし、クライアントウェブブラウザ２８に付加してもよい他の実行可能なコンポーネントもまた本発明の範囲内にあるものと見なされる。他のこれらの実行可能なコンポーネントは、限定としてではなく一例として、マイクロソフトデバイス上の．ＮＥＴスマートクライアント、任意のプラットフォーム上のモジラファイヤフォックス拡張機能、任意のプラットフォームと互換性があるフラッシュソフトウェア、任意のプラットフォームと互換性があるＪＡＶＡ（登録商標）ソフトウェア、またはアップルソフトウェアコンポーネントを有してもよい。プラグインコンポーネント３０は、クライアントコンピュータ１２が選択したクライアントウェブブラウザ２８と互換性がある。たとえばクライアントコンピュータ１２上のクライアントウェブブラウザ２８は、インターネットエクスプローラ、モジラファイヤフォックス、アップルサファリなどを有してもよい。プラグインコンポーネント３０は、クライアントコンピュータ１２上に組み込まれたクライアントウェブブラウザ２８に関連するキーストアファイルを特定する能力を有していることが重要である。クライアントウェブブラウザ２８に関連するキーストアファイルを特定した後に、公開鍵と秘密鍵とを有する鍵対をキーストアファイル内に保存してもよい。互いに異なるクライアントウェブブラウザ２８は、プラグインコンポーネント３０と理解されなければならずかつプラグインコンポーネント３０と互換性がなければならない、特有の統合プログラムライブラリを有している。たとえばマイクロソフトアプリケーションプログラミングインタフェース（ＡＰＩ）セットは、ＣＡＰＩＣＯＭライブラリを利用する。モジラファイヤフォックス用のＡＰＩセットは、ネットワークセキュリティサービス（ＮＳＳ）暗号ライブラリを有してもよい。アップルプラットフォームは、ＣＳＭＥライブラリを利用してもよい。認証機関（ＣＡ）が要求に署名してプラグインコンポーネント３０によって生成された鍵対の正当性を立証できるようにする公開鍵暗号化標準（ＰＫＣＳ）要求を生成するために、ライブラリを利用する。
【００３３】
再び図２のフローチャートを参照すると、方法は、証明書要求を生成するステップＳ１２０を続行してもよい。ここで図４を参照すると、クライアントコンピュータ１２上で証明書要求４２を生成する。クライアントウェブブラウザ２８のプラグインコンポーネント３０を利用してクライアントコンピュータ１２上で証明書要求４２を生成することを想定する。証明書要求４２は、プラグインコンポーネント３０によって生成された鍵対からの公開鍵を有する。本発明の一態様では、証明書要求４２がＰＫＣＳ＃１０であることを想定する。証明書要求４２は、証明要求情報と、署名アルゴリズム識別子と、証明要求情報上の電子署名と、の３つの部分で構成されている。証明要求情報は、クライアントの名前と、クライアントの公開鍵と、クライアントコンピュータ１２についての他の情報を提供する属性の集合と、から構成されている。それによって証明要求が構成されるプロセスは、下記のステップを有する。（１）証明を要求するクライアントコンピュータ１２によって、対象者の名前を有するＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値と、対象者の公開鍵と、必要に応じて属性の集合と、を構成する。（２）対象クライアントの秘密鍵を用いてＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値に署名する。（３）ＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値と、署名アルゴリズム識別子と、クライアントの署名とをＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔ値にいっしょにまとめる。認証機関は、要求しているクライアントを認証してクライアントの署名を検証し、要求が正当であるとき、名前と公開鍵と、発行者名と、通し番号と署名アルゴリズムとからの認証機関の選択と、から、Ｘ．５０９または他の電子証明書を構成することによって、要求を実現させる。
【００３４】
その後、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４に、証明書要求４２を送信してもよい。他の実施形態では、証明書要求４２を証明書サーバ４４に直接送信してもよい。また証明書要求４２は、クライアントウェブブラウザ２８を介して配信されることを想定する。証明書要求４２は、ＰＫＣＳ＃１０要求の形であってもよい。本発明の態様では、ＰＫＣＳ＃１０要求が、Ｘ．５０９証明書要求４２であることを想定する。本発明の一実施形態では、証明書サーバ４４は、認証機関である。証明書サーバ４４は、証明書要求４２に電子署名するように構成されている。本発明の他の実施形態では、証明書サーバ４４は、クライアントコンピュータ１２とサーバコンピュータ１４とから遠く離れたサーバである。本発明の他の実施形態では、証明書サーバ４４は、サーバコンピュータ１４でホストされていることを想定する。
【００３５】
本発明の他の実施形態に基づき、サーバソフトウェアアプリケーション３４は、保護されたＷＳＥ３．０ウェブサービスコールを介して証明書サーバ４４に通信する。図４に示す実施形態に基づき、証明書サーバ４４は、認証機関であり、サーバコンピュータ１４と企業データベース３６とを管理する組織から離れた正当な第三者プロバイダの制御範囲内にあると考えられている。図示されていない他の構成では、証明書サーバ４４と、テキストメッセージサーバ４０と、電話サーバ３８とは、サーバコンピュータ１４を管理しているのと同じ組織によって管理され維持されている。更に他の構成では、ウェブサービスに対する安全なアクセスを可能にしている。理解されるように、用語ウェブサービスは、コンピュータ同士の相互作用をサポートする標準化システムを指している。この場合、クライアントコンピュータ１２は、サーバコンピュータ１４を用いて認証するためにプラグインコンポーネント３０を利用する。このようにして生成されたクライアント証明書４８は、Ｗ３クライアントを認証するために利用され、クライアント証明書４８についての情報を利用してウェブサービスを用いて認証する
証明書サーバ４４において証明書要求４２を受信すると、次のステップＳ１３０は、図２のフローチャートに示すように、電子証明書メッセージを生成することを要求してもよい。証明書サーバ４４は、電子証明書メッセージを生成するように構成されている。証明書サーバ４４で生成された電子証明書メッセージは、元のＰＫＣＳ＃１０署名要求に対するＰＫＣＳ＃７応答の形で送信され、この元のＰＫＣＳ＃１０署名要求は、クライアントコンピュータ１２によって要求され、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４に送信されたものである。本発明の一実施形態のＰＫＣＳ＃７応答は、Ｘ．５０９証明書要求応答であってもよい。証明書要求応答は、署名された証明書要求としての署名証明書要求４６である。証明書サーバ４４は、証明書要求４２を処理して、署名証明書要求４６を生成するように構成されている。証明書要求４２の署名の後に、電子証明書メッセージは、署名証明書要求４６の形でサーバソフトウェアアプリケーション３４に送信される。本発明の他の実施形態では、署名証明書要求４６は、証明書サーバ４４から直接クライアントコンピュータ１２に送信される。この点において、クライアントウェブブラウザ２８は、署名証明書要求４６を受信するように構成されている。
【００３６】
ＰＫＣＳ＃７は、公開鍵基盤に基づきメッセージに署名する、および／または、メッセージを暗号化するために使用される。またＰＫＣＳ＃７は、ＰＫＣＳ＃１０メッセージに呼応して証明書を配布するために使用してもよい。それぞれ署名者のために、特定の署名者向けのメッセージダイジェストアルゴリズムを用いて、内容についてのメッセージダイジェストを計算する。署名者が内容以外の任意の情報を認証しているとき、内容と他の情報のメッセージダイジェストが署名者のメッセージダイジェストアルゴリズムを用いて要約され、その結果が「メッセージダイジェスト」になる。それぞれ署名者のために、メッセージダイジェストと関連情報を署名者の秘密鍵を用いて暗号化する。それぞれ署名者のために、暗号化されたメッセージダイジェストと他の特定の署名者向けの情報とをＳｉｇｎｅｒｌｎｆｏ値にまとめる。このステップでは、それぞれ署名者に対する証明書と証明
書取消リストと、どの署名者にも対応しない証明書と証明書取消リストとを収集する。すべての署名者に対するメッセージダイジェストアルゴリズムと、すべての署名者に対するＳｉｇｎｅｒｌｎｆｏ値とを、内容といっしょにＳｉｇｎｅｄＤａｔａ値にまとめる。受け手は、署名者の公開鍵を用いてそれぞれ署名者に対する暗号化されたメッセージダイジェストを解読し、その後、復元されたメッセージダイジェストと独自に計算したメッセージダイジェストとを比較することによって、署名を検証する。署名者の公開鍵は、署名者情報に含まれる証明書内に含まれているか、または公開鍵に対する証明書を一意的に特定する発行者名と、特定の発行者向けの通し番号とによって参照される。
【００３７】
再び図２のフローチャートを参照すると、フローチャートは、複数のクライアント証明書認証情報を保存するステップＳ１４０で終わる。署名証明書要求４６を、クライアントコンピュータ１２上でクライアントウェブブラウザ２８を介して受信する。一実施形態では、プラグインコンポーネント３０が、クライアントウェブブラウザ２８を介して受信される署名証明書要求４６を処理するように構成されていることを想定する。プラグインコンポーネント３０が、署名証明書要求４６を処理することに呼応して、クライアントコンピュータ１２は、クライアント証明書４８を生成する。本発明の一実施形態では、クライアントコンピュータ１２上でクライアント証明書４８を生成し、クライアント証明書４８を適切なキーストアファイル内に選択的に保存する。キーストアファイル内に複数のクライアント証明書認証情報を保存するのに使用者２６入力を必要としない。本発明の態様では、プラグインコンポーネント３０が、所要のキーストアファイル内に複数のクライアント証明書認証情報を自動的に保存するように構成されていることを想定する。プラグインコンポーネント３０は、１つのキーストアファイル内に、または複数のキーストアファイル内に、複数のクライアント証明書認証情報を選択的に保存してもよい。プラグインコンポーネント３０は、特定のキーストアファイル内に、または必要に応じて複数のキーストアファイル内に、複数のクライアント証明書認証情報を保存できる。
【００３８】
サーバコンピュータ１４に対するクライアントコンピュータ１２の単一認証では、複数のキーストアファイル内に鍵対の共通のセットを登録してもよい。これは、使用者２６がキーストアファイルをエクスポートしなければならず、その後、別のサーバ内に複数のクライアント証明書認証情報をインポートしなければならないという要件を回避する。この機能の向上は、互いに異なるプログラムサービスを利用して同じ暗号証明書認証情報を取り出すアプリケーションにとって重要である。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、最終の使用者２６に鍵対または他の証明書認証情報を手動でインポートとエクスポートすることを要求しない。またプラグインコンポーネント３０を有するクライアントウェブブラウザ２８は、サーバソフトウェアアプリケーション３４と証明書サーバ４４に通信しており、それによって、クライアントコンピュータ１２の認証後には、適切なキーストアファイル内に、または複数のキーストアファイル内に、複数のクライアント証明書認証情報を保存するのに使用者２６も手入力作業も必要としないようになっていることを想定する。
【００３９】
本発明の一実施形態では、暗号化されたキーストアファイルは、暗号鍵と証明書とに対する保存場所である。暗号化されたキーストアファイルは、それぞれ互いに異なるインタフェースを実現する互いに異なるエントリを管理してもよい。プラグインコンポーネント３０が、複数のクライアント証明書認証情報を、暗号化されたキーストアファイルの方向に向かって押すとき、システム内で利用可能な特定のキーストアファイルの種類の最も好ましい実施態様を戻すことによって達成されると想定される。
【００４０】
本発明の他の態様では、暗号化されたキーストアファイルの中に複数のクライアント証明書認証情報を保存するためにデフォルトインプリメンテーションを利用することを想定する。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、クライアン
トコンピュータ１２上に空いている暗号化されたキーストアファイルを生成するように構成されている。あるいは、空いている暗号化されたキーストアファイルを、クライアントウェブブラウザ２８のメモリ内に生成してもよい。
【００４１】
本明細書に示した詳細は、あくまで本発明の実施形態についての説明に役立つ議論を行うために、一例として示したに過ぎず、本発明の原理と概念的見地についての最も有用でかつ容易に理解される説明と考えられるものを提供するために提示している。この点について、本発明の基本的な理解のために必要である更なる詳細を示す試みは行っておらず、図面と合わせて説明を読めば、本発明の幾つかの形態を実際問題としてどのように具体化すればよいかについて当業者に明らかになる。
【技術分野】
【０００１】
本発明は、一般にクライアント証明書認証情報を保存するための方法とシステムに関し、更に詳細には本発明は、複数のクライアント証明書認証情報を、クライアントウェブブラウザを介してキーストアファイル内に自動的にクライアントセルフサービス保管するための方法とシステムに関する。
【背景技術】
【０００２】
公開鍵基盤（ＰＫＩ）は、事前の接触なしにコンピュータ間で互いに認証できるようにするとともに、それらの公開鍵証明書内の公開鍵情報を使用して互いに対するメッセージを暗号化できるようにする。一般に、公開鍵基盤は、クライアントソフトウェア、サーバソフトウェア、ハードウェア、および運用手順で構成されている。公開鍵基盤は、インターネットによる安全通信に関連する非常に重要な役割を果たしている。銀行業務、金融サービス、行政、教育、およびすべての種類の企業は、最新式コンピュータシステムとインターネットのようなデータ通信ネットワークとに依存している。このような進歩は、商取引を行う速度と利便性とを大幅に向上させてきたが、多くの脆弱性のために、やりとりされている機密性と極秘性の高いデータの安全性が危険にさらされている。最も基本的なレベルにおいて、電子商取引は、ネットワークを介して通信するサーバコンピュータシステムとクライアントコンピュータシステムとを通常有する。また付加的なクライアントまたはサーバコンピュータシステムをネットワークに接続して、複数のクライアントが所与のサーバにアクセスできたり、または所与のクライアントが複数のサーバにアクセスできたりするようになっていてもよい。このオープンネットワーク環境では、データ機密保護について３つの主要な懸案事項がある。まず第１に、クライアントは、それ自身が主張する通りのものであるということをサーバに対して保証しなければならない。第２に、サーバは、それ自身が主張する通りのものであるということをクライアントに対して保証しなければならない。第３に、正当なサーバと正当なクライアントの間でやりとりされている任意の情報は、ネットワーク上の他のいかなるコンピュータシステムまたは使用者によっても妨害されたり、または変更されたりしてはいけない。
【０００３】
たとえばエレクトロニックバンキングセッティングでは、銀行は、銀行用サーバにアクセスする使用者の身元を認証して、特定の顧客だけに関連する取引が許可されるようになっているとともに、銀行用サーバにアクセスする使用者が、その特定の顧客か、またはその特定の顧客が権限を与えた人であると確認されるようになっていなければならない。銀行用サーバが本当に銀行によって運用されている銀行用サーバであり、悪意があるエンティティによって運用されている類似の銀行用サーバではないことをクライアントに確保しなければならない。これはフィッシング攻撃として知られており、正当なサーバに似せて偽装サーバを作り、使用者をだまして銀行口座番号、社会保障番号、パスワード、およびその種の他のものなどの秘密情報を提供させるものである。負債の誤った累算、逮捕歴、刑事上の有罪判決、取引信用度の破壊、評判の棄損などを有する情報を有する犯罪者が、多くの損害を顧客に与える虞がある。またこれらは、「なりすまし犯罪」としても知られている。秘密情報がオープンネットワークを介して伝送されているため、このような情報は、暗号化されるか、さもなければクライアントとサーバ以外には、他のいかなるシステムにも分からないようにされる必要がある。ネットワークのオープン性によって、不正目的または悪意のある目的のために有効データ伝送を傍受して後で繰り返すリプレイアタックをコンピュータシステムが受けやすくなる。たとえばパスワードまたは他の認証情報が傍受されて、後で機密情報にアクセスするために使用される。更にネットワーク上で伝送されている情報は、介入者攻撃の場合などに変更可能であってはならない。これは、リンクが危険にさらされやすいことを正当なクライアントとサーバのどちらも認識することな
く、両者の間のデータを攻撃者が読み取り、挿入して、変更することを有する。
【０００４】
一般に、これらのセキュリティ問題は、機密データおよび／または極秘データをやりとりしているすべてのネットワーク環境において最重要課題である。多くの企業では、インターネットなどの公衆通信ネットワークを介して組織の内部ネットワーク資源に安全に遠隔アクセスするために、仮想専用ネットワーク（ＶＰＮ）を現在のところ利用している。上述した攻撃を防ぐ適切な防護対策が施されなければ、組織のデータのセキュリティも、組織の顧客のデータまたはクライアントのデータのセキュリティも危険にさらされて、１人の個人だけに与える損失よりも更に大きな損失をもたらす虞がある。
【０００５】
一般に、公開鍵暗号は、受け手と送り手の両方が保持する固有の公開鍵／秘密鍵対を有する。送り手の秘密鍵は、送り手だけで保持されており、受け手の秘密鍵は、受け手だけで保持されている。送り手の公開鍵は、配布されて、受け手によって保持され、受け手の公開鍵もまた配布されて、送り手によって保持される。メッセージを送信するときには、送り手の秘密鍵と受け手の公開鍵を使用してメッセージを暗号化する。メッセージは、受け手の秘密鍵と送り手の公開鍵とを用いて受け手によって解読される。
【０００６】
電子証明書は、信頼できる結びつきでクライアントの身元証明書とクライアントの公開鍵を関連付けるコンピュータで作成した記録である。信頼は、第三者の認証機関によって実施される登録証明書／身元証明書ポリシーに基づいている。証明書は、認証を発行する認証機関の身元証明書、クライアント、クライアントの公開鍵を有してもよく、証明書は、発行認証機関によって電子署名される。電子署名は、１つの装置を他の装置に対して認証するために使用される一般的な方法である。証明書は、電子署名と公開鍵暗号方式とで要求される鍵配布機構を提供する。電子署名を使用するために、署名を提供している装置上に個人情報（秘密鍵）を保存しなければならない。保存された個人情報は、秘密鍵を有するハードウェアデバイスを盗んだ攻撃者を助ける虞があり、たとえば攻撃者は、ルータ内に保存されたＲＳＡ秘密鍵を使用することによってルータに他のサイトへの安全な接続を開始させることができるかもしれない。
【０００７】
暗号作成法において周知の証明書規格は、Ｘ．５０９証明書である。証明書の構造は、バージョン、通し番号、アルゴリズムＩＤ、発行、有効期間、対象者、対象者の公開鍵情報、発行者の一意的識別子、対象者の一意的識別子、拡張、証明書署名アルゴリズム、および証明書署名を有してもよい。証明書は、国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）勧告であり、「ディレクトリ」で表される中央制御パラダイムに基づき認証サービスの規定の枠組みを定めている。勧告は、要求された身元の検証としてパスワードを使用する簡易認証と、暗号技術を使用することによって形成された認証情報、すなわち「証明書」を有する厳密認証と、の２つのレベルについて記述している。信頼を確立して維持することに関して認証機関の責任といっしょに証明書構造の形式を定めている。
【０００８】
Ｘ．５０９規格のような証明書、証明書チェーン、および秘密鍵は、キーストアファイルとして知られているものに保存される。通常、キーストアファイルは、ファイルの中に保存された情報を保護するために暗号化されている。キーストアファイル内に保存された情報は、上述のセキュリティ問題のため秘密になっている。キーストアファイルには、２つのパスワードを用いてアクセスしてもよい。１つのパスワードは、キーストアファイルへのアクセスを提供し、別の第２パスワードは、キーストアファイルの中に保存された秘密鍵へのアクセスを提供する。保護されたキーストアファイルのために開発された幾つかの規格がある。最も一般に普及しているのは、ＰＫＣＳ＃１２規格である。ＰＫＣＳ＃１２の規格は、付随の公開鍵証明書を備え、パスワードベースの対称鍵で保護された秘密鍵を保存するために一般的に使用されるファイル形式で定められたキーストアを提供する。これは、一例として複数の証明書を有する複数の埋め込みオブジェクトを有することがで
きるコンテナフォーマットである。この標準形式は、ＪＡＶＡ（登録商標）キーストアとともに使用してもよい。認証機関がクライアントに電子証明書を発行するとき、クライアントは、保護されたキーストアファイルを最終的に受取り、この保護されたキーストアファイルは、発行された証明書と、その証明書に対応する秘密鍵と、全体の証明書チェーンと、を含んでおり、証明書の信頼性を提供している。保護されたキーストアファイルは、クライアントにファイルの形でスマートカードとして渡してもよく、またはクライアントおよび／もしくはクライアントのウェブブラウザに直接インストールしてもよい。
【０００９】
最終の使用者の正当性を確保する形でインターネット全体にわたって認証するための実証された方法は、公開鍵／秘密鍵対を使用して認証要求に電子署名することである。このシナリオでは、使用者の秘密鍵を使ってメッセージに署名することによってクライアントがその身元を立証するであろうということを期待して、認証サーバがクライアントにメッセージを送信する。ほとんどの場合、このメッセージは、ＭＤ２、ＭＤ４、ＭＤ５、ＳＨＡ１または他の何らかのハッシュアルゴリズムなどの何らかの一般的なハッシュ機構を利用してデジタル処理でハッシュ化されたメッセージである。クライアントは、ハッシュを実行し、その後、使用者の秘密鍵を使ってこのハッシュに署名して、この電子署名されたメッセージをサーバに戻す。その後、サーバは、同じハッシュアルゴリズムを利用して同じメッセージをデジタル処理でハッシュして、この値を後で比較するために保存し、このハッシュ値は、「現在のハッシュ値」と呼ばれる。その後、サーバは、電子署名された署名をクライアントから受取り、使用者の公開鍵を使ってこのハッシュ値を解読する。その後、サーバは、この解読された電子署名と現在のハッシュ値を比較し、この２つが同じではない場合、その電子署名は、無効であり、検証は、失敗となる。発行手続きにおいてクライアントのウェブブラウザが役立つ可能性がある。
【００１０】
サーバまたはウェブサイトから所与の認証機関に送信した証明書発行要求（証明書要求）において、クライアントのウェブブラウザは、公開鍵／秘密鍵対を生成してもよく、認証機関のサーバにその公開鍵を送信する。クライアントウェブブラウザは、秘密鍵を秘密にしておき、認証機関には、秘密鍵を送信しない。認証機関は、クライアントの個人の身元データの信頼性を検証した後に、クライアントのウェブブラウザが受信した公開鍵とクライアントの確認された身元データとを記録している証明書をクライアントに発行する。認証機関のサーバがそのクライアントに証明書を発行した後に、認証機関は、証明書をクライアントのウェブブラウザ内にインストールすることができるウェブページにクライアントをリダイレクトする。ウェブブラウザは、証明書に対応する秘密鍵を保存しており、最後には、使用者は、証明書の、クライアントのウェブブラウザ内にインストールされた証明書チェーンとともに、証明書とそれに対応する秘密鍵とを入手する。秘密鍵を保存する方法は、ウェブブラウザに応じて一般に変化する。
【００１１】
ほとんどのクライアントウェブブラウザは、認証用に安全なＳＳＬサーバの中に保存された証明書と秘密鍵とを使用することができる。また多くのＥ−ｍａｉｌクライアントは、クライアントウェブブラウザ内に保存された証明書を使用して、電子メールに署名し、暗号化し、解読することもできる。しかし、幾つかのアプリケーションは、クライアントのウェブブラウザからの証明書を直接使用することはできないが、特定のキーストアファイルとともに動作できる。このような場合には、クライアントの使用者は、それらのクライアントウェブブラウザからのそれらの証明書を、キーストアファイル内のそれらの証明書に対応する秘密鍵といっしょにエクスポートして、他の任意のアプリケーションでそれらを使用してもよい。Ｘ．５０９電子証明書を保存するための幾つかの規格がある。ＡＳＮ．１ ＤＥＲ符号化が最もよく使用され、この符号化では、証明書は、．ＣＥＲ拡張子を有するファイル内に保存される。．ＣＥＲファイルは、公開鍵と、その公開鍵の所有者の情報と、その公開鍵が本当にその使用者またはクライアントに帰属することを証明する認証機関の電子署名と、を有する。認証機関は、認証機関のサイトから、．ＣＥＲファイ
ル内の認証機関のルート証明書を配布する。．ＣＥＲファイルは、バイナリ形式またはＢａｓｅ６４で符号化されたテキスト形式で保存できる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許出願公開第２００４／２６８１４８号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、多くのキーストアファイルアプリケーションは、認証機構とは無関係である。これらのキーストアファイルアプリケーションは、複数の記憶領域内の公開鍵／秘密鍵を検索して利用する。これらの第三者製のアプリケーションは、公開鍵／秘密鍵、または他のキーストアファイルロケーション内の他の証明書認証情報を通常検索できない。あるいは第三社製のアプリケーションは、アプリケーションが書き直された後にだけ、他のキーストアファイルロケーション内の複数のクライアント証明書認証情報を検索してもよい。通常そのアプリケーションでは、検索するように設計されていないキーストアファイルロケーションを検索するように、サードパーティ製アプリケーションを書き直すことは困難であり、クライアントコンピュータのほとんどの使用者には、推奨できない。
【００１４】
よくある問題は、アプリケーションが、ＪＡＶＡ（登録商標）キーストア内に保存される予定の複数のクライアント証明書認証情報を探す点である。ほとんどの認証ソリューションでは、ブラウザ専用のキーストアファイル内に複数のクライアント証明書認証情報を保存しているため、アプリケーションは、認証情報を見つけることができず、その結果、使用者を認証しない虞があり、従ってアプリケーションが役に立たなくなる。この問題に対する過去の解決方法は、使用者が手動で証明書情報を抽出して他のキーストアファイル内に複製することであった。しかし上述したように、これは間違いを犯しやすい困難な手順であり、ほとんどの使用者の技術能力を超えてしまう。
【課題を解決するための手段】
【００１５】
よって当技術分野において、１つのキーストアファイルまたは複数のキーストアファイルの中にクライアント証明書認証情報を保存するための改良された方法とシステムに対する必要性が存在している。
【００１６】
本発明の一実施形態に基づき、クライアントウェブブラウザを介してキーストアファイルに複数のクライアント証明書認証情報を保存するための方法を提供する。方法は、クライアントとサーバの間の安全なデータ転送リンクを確立するステップで始まる。クライアントウェブブラウザを使用してクライアントとサーバの間の安全なデータ転送リンクを確立する。クライアントウェブブラウザは、プラグインソフトウェアコンポーネントを有する。プラグインソフトウェアコンポーネントは、クライアントとサーバの間に安全なデータ転送リンクを確立するプロセスの間に、キーストアファイルと、公開鍵と秘密鍵とを有する鍵対と、を生成するように構成されている。方法は、クライアント上で証明書要求を生成するステップを続けてもよい。生成された証明書要求は、プラグインソフトウェアコンポーネントによって生成された鍵対からクライアントウェブブラウザへの公開鍵を有する。その後、生成された証明書要求を証明書サーバに送信する。証明書サーバは、生成された証明書要求に電子署名するように構成されている。方法は、署名証明書要求をクライアントが受信するステップを続ける。署名証明書要求は、クライアントウェブブラウザを介してクライアントによって受信される。方法は、署名証明書要求に関連する複数のクライアント証明書認証情報をキーストアファイル内に保存するステップで終わってもよい。
【００１７】
本発明の他の実施形態に基づき、複数のクライアント証明書認証情報は、電子証明書、
秘密鍵、公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する。本発明の他の態様では、クライアントとサーバの間の安全なデータ転送リンクを確立するステップは、サーバを用いた多元的認証過程の完了を成功させるようにクライアントに要求する。またプラグインソフトウェアコンポーネントがサーバからクライアントウェブブラウザに送信されたブラウザ実行コードであることを想定する。プラグインソフトウェアコンポーネントは、複数のキーストアファイルを生成するように構成されていてもよい。プラグインソフトウェアコンポーネントは、複数のクライアント証明書認証情報を選択的に保存してもよい。プラグインソフトウェアコンポーネントによって選択的に保存される予定の複数のクライアント証明書認証情報は、署名証明書要求に関連している。複数のクライアント証明書認証情報は、プラグインソフトウェアコンポーネントによって生成された複数のキーストアファイル内に保存してもよい。また方法は、サーバがセキュアソケットレイヤ（ＳＳＬ）仮想専用ネットワーク（ＶＰＮ）であることを想定する。また証明書サーバがクライアントとサーバとから遠く離れた認証機関であることを想定する。複数のクライアント証明書認証情報を保存するために選択される予定のキーストアファイルは、マイクロソフト暗号ＡＰＩキーストアと、ＪＡＶＡ（登録商標）キーストアと、アップルキーストアと、ＮＳＳキーストアと、からなる群から選択されてもよい。しかし、上述のキーストアの種類は、あくまで実施例を示したに過ぎず、本発明は、実施例としてここに示していない付加的なキーストアを利用することを想定する。プラグインソフトウェアコンポーネントは、クライアントウェブブラウザを確認して、クライアントウェブブラウザの符号化ライブラリに関連するキーストアファイル内に複数のクライアント証明書認証情報を保存してもよい。
【００１８】
本発明の更に他の実施形態では、複数のクライアント証明書認証情報を保存するためのシステムを提供する。システムは、クライアントとサーバの間の安全なデータ転送リンクを確立するためにクライアント上にクライアントウェブブラウザを有する。またシステムは、複数のキーストアファイルを有する。複数のキーストアファイルは、クライアントウェブブラウザによって生成される。またシステムは、証明書サーバを有してもよい。証明書サーバは、クライアントによって生成された証明書要求を受信できる。証明書サーバは、証明書要求に電子署名するように構成されている。システムは、プラグインソフトウェアコンポーネントを有する。プラグインソフトウェアコンポーネントは、クライアントウェブブラウザへのアドオンである。クライアントウェブブラウザは、プラグインソフトウェアコンポーネントを処理して公開鍵と秘密鍵とを有する鍵対を生成する。またプラグインソフトウェアコンポーネントは、複数のクライアント証明書認証情報を選択的に保存するように構成されている。本発明の態様は、プラグインソフトウェアコンポーネントが複数のキーストアファイルから少なくとも１つのキーストアファイル内に複数のクライアント証明書認証情報を保存することを想定する。本発明の他の実施形態では、プラグインソフトウェアコンポーネントは、複数のキーストアファイル内に複数のクライアント証明書認証情報を保存する。
【００１９】
またキーストアファイル内に選択的に保存される予定の複数のクライアント証明書認証情報は、電子証明書、クライアント秘密鍵、クライアント公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有することを想定する。システムのクライアントウェブブラウザは、サーバを用いた多元的認証過程の完了に成功することによって、安全なデータ転送リンクを確立する。システム内に含まれる証明書サーバは、クライアントとサーバとから遠く離れた認証機関である。本発明の他の実施形態では、証明書サーバは、サーバでホストされている。システムのクライアントウェブブラウザは、電子証明書を生成するように構成されている。電子証明書は、署名証明書要求の受信に呼応して通常生成される。電子証明書は、証明書サーバによって検証された情報を有するであろう。システムのプラグインソフトウェアコンポーネントは、サーバからクライアントウェブブラウザに送信されたブラウザ実行コードである。本発明の他の実施形態では、プラグインソフトウ
ェアコンポーネントは、サーバから独立しているクライアント上のインストール過程を通してクライアントウェブブラウザに付加されたブラウザ実行コードである。
【００２０】
同じ要素を示すために図面と詳細な説明の全体を通して共通の参照番号を使用している。
本発明は、添付図面とともに以下の詳細な説明を参照することによって、最も良く理解されるであろう。
【００２１】
本明細書で開示したさまざまな実施形態の、これらのおよび他の特徴、ならびに利点は、以下の説明と図面を参照することによって、より良く理解されるであろう。
添付図面に関連して以下に示す詳細な説明は、本発明の現在の好ましい実施形態を説明するものであり、本発明を構成したり、または利用したりしてもよい唯一の形態を示すものではない。説明は、図示の実施形態に関連して本発明を開発して運用するためのステップの機能と順序を示している。しかし、それもまた有するように意図されている互いに異なる実施形態によって、同じまたは等価な機能と順序を達成してもよいことを理解すべきである。当然のことながら、第１と第２の、ならびにその種の他のものなどの関係用語の使用は、１つのエンティティと他のエンティティを区別するためにだけ使用されており、このようなエンティティの間の実際のこのような関係または順序を必ずしも要求したり、または示唆したりするわけではない。
【図面の簡単な説明】
【００２２】
【図１】本発明の一態様が実現可能な環境を示すブロック図。さまざまな相互接続されたサーバ、クライアント、および仮想専用ネットワーク（ＶＰＮ）を有する。
【図２】本発明の態様の複数のクライアント証明書認証情報を保存するための方法を示すフローチャート。
【図３】サーバに対するクライアントの認証に呼応して、クライアント証明書認証情報を保存するための第１例示的構成。
【図４】本発明の一態様が実現可能な環境を示す第２例示的構成。
【発明を実施するための形態】
【００２３】
図１を参照すると、例示的なコンピュータネットワーク１０は、さまざまなデータ処理装置またはコンピュータとしてのクライアントコンピュータ１２と、サーバコンピュータ１４とを有する。更に詳細には、クライアントコンピュータ１２は、クライアントとして機能するパーソナルコンピュータまたはワークステーションであってもよく、中央演算処理装置と、記憶デバイスと、その種の他のものとを内蔵するシステム装置１６を有してもよい。またクライアントコンピュータ１２は、表示装置１８と、キーボード２０ａおよびマウス２０ｂのような入力装置２０と、を有してもよい。システム装置１６は、中央演算処理装置で現在実行中の前もってプログラムされた命令の制御とフローとを変更するさまざまな入力を入力装置２０から受信し、このような実行処理の結果を表示装置１８上に示すことが分かる。サーバコンピュータ１４は、クライアントコンピュータ１２にデータまたはサービスを提供するサーバであってもよい。この点について、用語「クライアント」は、データまたはサービスのリクエスタとしてのクライアントコンピュータ１２の役割を指していると理解され、他方、用語「サーバ」は、このようなデータまたはサービスを提供するサーバコンピュータ１４の役割を指していると理解される。更にクライアントコンピュータ１２は、１つのトランザクション内でデータまたはサービスを要求してもよく、トランザクション内でデータまたはサービスを提供してもよく、このように、その役割をクライアントからサーバに、またはその逆に変えることができる。また更に当然のことながら、本明細書で利用されているような用語「サーバ」は、一般に、セキュアソケットレイヤ／トランスポートレイヤセキュリティ（ＳＳＬ／ＴＬＳ）仮想専用ネットワーク（ＶＰＮ）などのネットワークサービスを指してもよく、このネットワークサービスを通じて
、従来のサーバコンピュータ１４は、リモートクライアントにデータとソフトウェアアプリケーションを提供する。
【００２４】
クライアントコンピュータ１２とサーバコンピュータ１４は、ネットワーク接続２４を介してインターネット２２などの広域ネットワークに接続されている。クライアントコンピュータ１２からの要求と、サーバコンピュータ１４から要求されたデータとは、ネットワーク接続２４を介して配信される。本発明の実施形態に基づき、サーバコンピュータ１４は、ウェブサーバであり、クライアントコンピュータ１２は、サーバコンピュータ１４によって提供された資料を表示装置１８上に視覚的に描画するマイクロソフト社のインターネットエクスプローラのようなウェブ閲覧アプリケーションを有してもよい。当然のことながら、図１に示したネットワークトポロジは、限定としてではなく、あくまで一例を示したに過ぎず、本発明の範囲を逸脱することなく、他の任意の種類のローカルエリアネットワークまたは広域エリアネットワークを容易に代わりとして使用してもよい。ネットワーク接続２４とインターネット２２に対して、周知の任意のデータ転送プロトコルを利用してもよいことが分かる。
【００２５】
さらなる実施例では、第１サーバコンピュータ１４ａは、課金情報と資金移動機能を提供するエレクトロニックバンキングウェブサーバであってもよい。また付加的な使用法も想定され、その使用法では、第１サーバコンピュータ１４ａは、メールサーバ、オンラインショッピングサイト、またはマイクロソフト社の．ＮＥＴアプリケーションをホスティングする。第１クライアントコンピュータ１２ａの使用者は、第１サーバコンピュータ１４ａにログオンして、クライアントウェブブラウザを用いて勘定残高を読み出し、資金を別の口座に移動させてもよい。この例示的状況では、情報セキュリティの問題の１つは、第１クライアントコンピュータ１２ａの使用者が、彼がそうであると主張する人本人であることを確保することを有する。たとえば第２クライアントコンピュータ１２ｂの悪意のある使用者が、第１クライアントコンピュータ１２ａの使用者の認証情報のすべてを有しており、このようなアクセスが不正であると認識せずに第１サーバコンピュータ１４ａにログオンする虞がある。他の問題は、第１サーバコンピュータ１４ａが銀行の管理下にあり、第１クライアントコンピュータ１２ａの使用者がその銀行の顧客であることを確保することである。フィッシング攻撃で第２サーバコンピュータ１４ｂが第１サーバコンピュータ１４ａになりすましている虞があるかもしれず、第１クライアントコンピュータ１２ａが、間違って第２サーバコンピュータ１４ｂにアクセスしてしまう虞がある。更に第１クライアントコンピュータ１２ａと第１サーバコンピュータ１４ａの間のすべての正当なデータ転送は、第３クライアントコンピュータ１２ｃと、第２クライアントコンピュータ１２ｂと、第２サーバコンピュータ１４ｂとを有する他のいかなるコンピュータによっても傍受されてはならない。
【００２６】
上述したように、特定の第１サーバコンピュータ１４ａにアクセスする代わりに、クライアントコンピュータ１２は、仮想専用ネットワーク（ＶＰＮ）１５にアクセスしてもよい。仮想専用ネットワーク１５は、仮想専用ネットワークルータ１７を介してインターネット２２に接続され、クライアントコンピュータ１２への遠隔アクセスを可能にしてもよい。仮想専用ネットワークルータ１７は、外部のクライアントコンピュータ１２がローカルネットワーク１９上の仮想サーバコンピュータ１４ｃにアクセスできる唯一の様態であることが分かる。上述したのと同じ安全上の懸念が仮想専用ネットワーク１５にも同様に適用できるため、更に詳細に後述するように本発明の方法とシステムを実現する可能性があると想定される。
【００２７】
図２のフローチャートを参照すると、図は、複数のクライアント証明書認証情報をキーストアファイル内に選択的に保存するためのさまざまなステップを示している。キーストアファイルは、鍵対のインメモリコレクションと、電子証明書と、他のクライアント証明
書認証情報とである。たとえばキーストアファイルは、機密性の高い暗号鍵情報を保持していてもよく、この暗号鍵情報は、不正アクセスを防ぐために保護フォーマット内に保存されている。通常、この種類のエントリ内に保存される認証情報は、対応する公開鍵に対する証明書チェーンをともなう秘密鍵である。秘密鍵と証明書チェーンは、自己認証を行うために所与のエンティティによって使用される。信頼できる証明書エントリは、他の当事者に属する単一の公開鍵証明書を有する。その単一の公開鍵証明書は、証明書内の公開鍵が証明書の対象者（所有者）によって確認された身元に帰属していることをキーストアファイル所有者が信じるため、信頼できる証明書と呼ばれる。証明書キーストアファイルに対する登録プロセスは、専用のクライアントソフトおよび／または手動の管理者起動プロセスに通常基づいている。更にこのプロセスは、クライアントコンピュータ１２の使用者に任せてもよい。しかし、暗号化されたキーストアファイルのセキュリティは、多元的認証に基づいてもよい。
【００２８】
特に、図２に開示したフローチャートの第１ステップＳ１００は、クライアントコンピュータ１２とサーバコンピュータ１４の間の安全なデータ転送リンクを確立することを想定する。本発明の一実施形態では、クライアントコンピュータ１２をサーバコンピュータ１４に対して認証するのに成功した後にだけ、安全なデータ転送リンクが確立されることを想定する。サーバコンピュータ１４に対してクライアントコンピュータ１２を認証する過程は、多元的認証を有する。ここで図３を参照すると、クライアントの多元的認証過程を示している。サーバコンピュータ１４を用いてクライアントコンピュータ１２を登録して多元的認証過程を完了するのに成功することで、クライアントコンピュータ１２が詐欺師またはハッカーではないことを確保するとともにクライアントコンピュータ１２とサーバコンピュータ１４の間のすべての通信を保護することによって、クライアントコンピュータ１２とサーバコンピュータ１４の間の安全なデータ転送リンクを確立してもよい。クライアントコンピュータ１２の使用者２６は、サーバコンピュータ１４を用いて安全ではない接続を確立することによって、登録と認証過程を開始してもよい。たとえば使用者２６は、クライアントコンピュータ１２上のクライアントウェブブラウザ２８つまりクライアントブラウザに、サーバコンピュータ１４に関連するネットワークアドレスを入力してもよく、その時点でサーバコンピュータ１４上のファイルまたはウェブページに対する要求が出される。それに呼応して、サーバコンピュータ１４は、クライアントコンピュータ１２の使用者２６がサーバコンピュータ１４にアクセスする権限を与えられているか否か判断するための情報を要求してもよい。
【００２９】
クライアントコンピュータ１２とサーバコンピュータ１４の間で想定される相互作用は、クライアントコンピュータ１２がクライアントウェブブラウザ２８を介してサーバコンピュータ１４にログオンすることを有してもよい。要求される情報は、たとえばユーザ名またはパスワードを有してもよい。その後、クライアントコンピュータ１２上のクライアントウェブブラウザ２８は、使用者２６に、サーバコンピュータ１４にアクセスするためのユーザ名および／またはパスワードの入力を要求する。その後、サーバコンピュータ１４は、クライアントコンピュータ１２の使用者２６が提供した情報が正しいか否か判断してもよい。サーバコンピュータ１４は、サーバソフトウェアアプリケーション３４を介して企業データベース３６に通信してもよく、この企業データベース３６は、バックエンドデータストアの役割を果たしてもよい。企業データベース３６は、使用者２６が正しい身元確認情報を提供したか否か判断するために、使用者２６のユーザ名とパスワードを有してもよい。本発明の一実施形態では、企業データベース３６は、サーバコンピュータ１４によってホストされている。他の実施形態では、企業データベース３６は、ネットワーク接続２４またはインターネット２２を介してサーバソフトウェアアプリケーション３４に通信するリモートサーバである。サーバコンピュータ１４は、アクティブディレクトリサーバ、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）サーバ、データベースサーバなどであってもよい。サーバソフトウェアアプリケーション３４は、サーバコン
ピュータ１４によってホストされている。サーバソフトウェアアプリケーション３４は、クライアントウェブブラウザ２８に通信すること、従ってクライアントコンピュータ１２に通信することを想定している。
【００３０】
クライアントコンピュータ１２の認証に成功する前に、帯域外の様態を介してクライアントコンピュータ１２とそれに関連する使用者２６を認証できる。一実施形態に基づき、サーバソフトウェアアプリケーション３４は、使用者２６の管理下にある携帯電話または有線電話に使い捨てパスワードを配信するように電話サーバ３８に通知する。あるいは、テキストメッセージサーバ４０から電子メールまたはショートメッセージサービス（ＳＭＳ）テキストメッセージを送信してもよい。音声認識、ＩＰアドレス検証、およびその種の他のものなどの他の帯域外認証技術が想定される。使い捨てパスワードのエントリは、サーバコンピュータ１４を通してサーバソフトウェアアプリケーション３４を用いて処理してもよい。上述の帯域外認証の代わりに、または上述の帯域外認証に加えて、付加的な知識ベース認証方式を使用者２６に提示してもよい。たとえば使用者２６に、彼らの好みの色、彼らの母親の旧姓、および他の同様の質問を尋ねてもよい。サーバソフトウェアアプリケーション３４を用いて後で読み出して使用するために、付加的な認証情報を企業データベース３６内に保存してもよい。上述の手続きは、サーバコンピュータ１４を用いてクライアントコンピュータ１２上のクライアントウェブブラウザ２８を「登録」して、このようなクライアントウェブブラウザ２８を効果的に第２認証要素（「使用者が有している何か」）にすることが分かる。上述したように、使い捨てパスワードは、クライアントコンピュータ１２とサーバコンピュータ１４の間のデータ通信リンクとは無関係な、またはクライアントコンピュータ１２とサーバコンピュータ１４の間のデータ通信リンクに関して帯域外の、通信様態を介して配信される。電話サーバ３８は、第三者、またはサーバコンピュータ１４もしくは企業データベース３６を管理する組織、が管理してもよい。サーバソフトウェアアプリケーション３４は、クライアントコンピュータ１２の使用者２６に正式な応答を入力するように指示する。この線に沿って、電話サーバ３８と、クライアントコンピュータ１２に正式な応答を送信するステップとは、省略してもよいことが分かり、ここで「正式な応答」とは、知識ベースの質問に対する回答である。この回答は、その時以前に使用者２６が決めたものと想定される。
【００３１】
多元的認証過程を通して安全なデータ転送リンクを確立した後で、図２のフローチャートの次のステップＳ１１０は、複数のクライアント証明書認証情報を生成することを有する。複数のクライアント証明書認証情報は、公開鍵と秘密鍵とで構成された鍵対を有してもよい。またこのステップは、複数のクライアント証明書認証情報を保存するためのキーストアファイルを生成することを想定する。再び図３を参照すると、クライアント装置としてのクライアントコンピュータ１２上のクライアントウェブブラウザ２８は、安全なデータ転送リンクの確立に呼応してキーストアファイルと鍵対とを生成するプラグインソフトウェアコンポーネントとしてのプラグインコンポーネント３０を有する。本発明の態様では、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４を用いた認証が成功した後に、プラグインコンポーネント３０が鍵対を生成することを想定する。本発明の一実施形態では、プラグインコンポーネント３０は、クライアントウェブブラウザ２８へのアドオンとして実現されるブラウザ実行コードである。安全なデータ転送リンクを確立した後に、プラグインコンポーネント３０をサーバコンピュータ１４から送信してもよい。また安全なデータ転送リンクを確立する前に、プラグインコンポーネント３０をクライアントウェブブラウザ２８に送信してもよいことが想定される。更にプラグインコンポーネント３０を有するブラウザ実行コードを、クライアントコンピュータ１２上に、従ってサーバコンピュータ１４とは無関係にクライアントウェブブラウザ２８上に、インストールしてもよい。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、クライアントコンピュータ１２上で処理されて、１つのキーストアファイルまたは複数のキーストアファイルを生成する。またクライアントコンピュータ１２上
でのプラグインコンポーネント３０の処理によって、サーバコンピュータ１４を用いたクライアントコンピュータ１２の認証の成功に呼応して、鍵対を生成してもよい。
【００３２】
一実施形態に基づき、プラグインコンポーネント３０は、クライアントウェブブラウザ２８を介してシングルユーザ２６インタラクションを用いてインストールされるＡｃｔｉｖｅ−Ｘコンポーネントである。しかし、クライアントウェブブラウザ２８に付加してもよい他の実行可能なコンポーネントもまた本発明の範囲内にあるものと見なされる。他のこれらの実行可能なコンポーネントは、限定としてではなく一例として、マイクロソフトデバイス上の．ＮＥＴスマートクライアント、任意のプラットフォーム上のモジラファイヤフォックス拡張機能、任意のプラットフォームと互換性があるフラッシュソフトウェア、任意のプラットフォームと互換性があるＪＡＶＡ（登録商標）ソフトウェア、またはアップルソフトウェアコンポーネントを有してもよい。プラグインコンポーネント３０は、クライアントコンピュータ１２が選択したクライアントウェブブラウザ２８と互換性がある。たとえばクライアントコンピュータ１２上のクライアントウェブブラウザ２８は、インターネットエクスプローラ、モジラファイヤフォックス、アップルサファリなどを有してもよい。プラグインコンポーネント３０は、クライアントコンピュータ１２上に組み込まれたクライアントウェブブラウザ２８に関連するキーストアファイルを特定する能力を有していることが重要である。クライアントウェブブラウザ２８に関連するキーストアファイルを特定した後に、公開鍵と秘密鍵とを有する鍵対をキーストアファイル内に保存してもよい。互いに異なるクライアントウェブブラウザ２８は、プラグインコンポーネント３０と理解されなければならずかつプラグインコンポーネント３０と互換性がなければならない、特有の統合プログラムライブラリを有している。たとえばマイクロソフトアプリケーションプログラミングインタフェース（ＡＰＩ）セットは、ＣＡＰＩＣＯＭライブラリを利用する。モジラファイヤフォックス用のＡＰＩセットは、ネットワークセキュリティサービス（ＮＳＳ）暗号ライブラリを有してもよい。アップルプラットフォームは、ＣＳＭＥライブラリを利用してもよい。認証機関（ＣＡ）が要求に署名してプラグインコンポーネント３０によって生成された鍵対の正当性を立証できるようにする公開鍵暗号化標準（ＰＫＣＳ）要求を生成するために、ライブラリを利用する。
【００３３】
再び図２のフローチャートを参照すると、方法は、証明書要求を生成するステップＳ１２０を続行してもよい。ここで図４を参照すると、クライアントコンピュータ１２上で証明書要求４２を生成する。クライアントウェブブラウザ２８のプラグインコンポーネント３０を利用してクライアントコンピュータ１２上で証明書要求４２を生成することを想定する。証明書要求４２は、プラグインコンポーネント３０によって生成された鍵対からの公開鍵を有する。本発明の一態様では、証明書要求４２がＰＫＣＳ＃１０であることを想定する。証明書要求４２は、証明要求情報と、署名アルゴリズム識別子と、証明要求情報上の電子署名と、の３つの部分で構成されている。証明要求情報は、クライアントの名前と、クライアントの公開鍵と、クライアントコンピュータ１２についての他の情報を提供する属性の集合と、から構成されている。それによって証明要求が構成されるプロセスは、下記のステップを有する。（１）証明を要求するクライアントコンピュータ１２によって、対象者の名前を有するＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値と、対象者の公開鍵と、必要に応じて属性の集合と、を構成する。（２）対象クライアントの秘密鍵を用いてＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値に署名する。（３）ＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ値と、署名アルゴリズム識別子と、クライアントの署名とをＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔ値にいっしょにまとめる。認証機関は、要求しているクライアントを認証してクライアントの署名を検証し、要求が正当であるとき、名前と公開鍵と、発行者名と、通し番号と署名アルゴリズムとからの認証機関の選択と、から、Ｘ．５０９または他の電子証明書を構成することによって、要求を実現させる。
【００３４】
その後、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４に、証明書要求４２を送信してもよい。他の実施形態では、証明書要求４２を証明書サーバ４４に直接送信してもよい。また証明書要求４２は、クライアントウェブブラウザ２８を介して配信されることを想定する。証明書要求４２は、ＰＫＣＳ＃１０要求の形であってもよい。本発明の態様では、ＰＫＣＳ＃１０要求が、Ｘ．５０９証明書要求４２であることを想定する。本発明の一実施形態では、証明書サーバ４４は、認証機関である。証明書サーバ４４は、証明書要求４２に電子署名するように構成されている。本発明の他の実施形態では、証明書サーバ４４は、クライアントコンピュータ１２とサーバコンピュータ１４とから遠く離れたサーバである。本発明の他の実施形態では、証明書サーバ４４は、サーバコンピュータ１４でホストされていることを想定する。
【００３５】
本発明の他の実施形態に基づき、サーバソフトウェアアプリケーション３４は、保護されたＷＳＥ３．０ウェブサービスコールを介して証明書サーバ４４に通信する。図４に示す実施形態に基づき、証明書サーバ４４は、認証機関であり、サーバコンピュータ１４と企業データベース３６とを管理する組織から離れた正当な第三者プロバイダの制御範囲内にあると考えられている。図示されていない他の構成では、証明書サーバ４４と、テキストメッセージサーバ４０と、電話サーバ３８とは、サーバコンピュータ１４を管理しているのと同じ組織によって管理され維持されている。更に他の構成では、ウェブサービスに対する安全なアクセスを可能にしている。理解されるように、用語ウェブサービスは、コンピュータ同士の相互作用をサポートする標準化システムを指している。この場合、クライアントコンピュータ１２は、サーバコンピュータ１４を用いて認証するためにプラグインコンポーネント３０を利用する。このようにして生成されたクライアント証明書４８は、Ｗ３クライアントを認証するために利用され、クライアント証明書４８についての情報を利用してウェブサービスを用いて認証する
証明書サーバ４４において証明書要求４２を受信すると、次のステップＳ１３０は、図２のフローチャートに示すように、電子証明書メッセージを生成することを要求してもよい。証明書サーバ４４は、電子証明書メッセージを生成するように構成されている。証明書サーバ４４で生成された電子証明書メッセージは、元のＰＫＣＳ＃１０署名要求に対するＰＫＣＳ＃７応答の形で送信され、この元のＰＫＣＳ＃１０署名要求は、クライアントコンピュータ１２によって要求され、サーバコンピュータ１４上にホストされたサーバソフトウェアアプリケーション３４に送信されたものである。本発明の一実施形態のＰＫＣＳ＃７応答は、Ｘ．５０９証明書要求応答であってもよい。証明書要求応答は、署名された証明書要求としての署名証明書要求４６である。証明書サーバ４４は、証明書要求４２を処理して、署名証明書要求４６を生成するように構成されている。証明書要求４２の署名の後に、電子証明書メッセージは、署名証明書要求４６の形でサーバソフトウェアアプリケーション３４に送信される。本発明の他の実施形態では、署名証明書要求４６は、証明書サーバ４４から直接クライアントコンピュータ１２に送信される。この点において、クライアントウェブブラウザ２８は、署名証明書要求４６を受信するように構成されている。
【００３６】
ＰＫＣＳ＃７は、公開鍵基盤に基づきメッセージに署名する、および／または、メッセージを暗号化するために使用される。またＰＫＣＳ＃７は、ＰＫＣＳ＃１０メッセージに呼応して証明書を配布するために使用してもよい。それぞれ署名者のために、特定の署名者向けのメッセージダイジェストアルゴリズムを用いて、内容についてのメッセージダイジェストを計算する。署名者が内容以外の任意の情報を認証しているとき、内容と他の情報のメッセージダイジェストが署名者のメッセージダイジェストアルゴリズムを用いて要約され、その結果が「メッセージダイジェスト」になる。それぞれ署名者のために、メッセージダイジェストと関連情報を署名者の秘密鍵を用いて暗号化する。それぞれ署名者のために、暗号化されたメッセージダイジェストと他の特定の署名者向けの情報とをＳｉｇｎｅｒｌｎｆｏ値にまとめる。このステップでは、それぞれ署名者に対する証明書と証明
書取消リストと、どの署名者にも対応しない証明書と証明書取消リストとを収集する。すべての署名者に対するメッセージダイジェストアルゴリズムと、すべての署名者に対するＳｉｇｎｅｒｌｎｆｏ値とを、内容といっしょにＳｉｇｎｅｄＤａｔａ値にまとめる。受け手は、署名者の公開鍵を用いてそれぞれ署名者に対する暗号化されたメッセージダイジェストを解読し、その後、復元されたメッセージダイジェストと独自に計算したメッセージダイジェストとを比較することによって、署名を検証する。署名者の公開鍵は、署名者情報に含まれる証明書内に含まれているか、または公開鍵に対する証明書を一意的に特定する発行者名と、特定の発行者向けの通し番号とによって参照される。
【００３７】
再び図２のフローチャートを参照すると、フローチャートは、複数のクライアント証明書認証情報を保存するステップＳ１４０で終わる。署名証明書要求４６を、クライアントコンピュータ１２上でクライアントウェブブラウザ２８を介して受信する。一実施形態では、プラグインコンポーネント３０が、クライアントウェブブラウザ２８を介して受信される署名証明書要求４６を処理するように構成されていることを想定する。プラグインコンポーネント３０が、署名証明書要求４６を処理することに呼応して、クライアントコンピュータ１２は、クライアント証明書４８を生成する。本発明の一実施形態では、クライアントコンピュータ１２上でクライアント証明書４８を生成し、クライアント証明書４８を適切なキーストアファイル内に選択的に保存する。キーストアファイル内に複数のクライアント証明書認証情報を保存するのに使用者２６入力を必要としない。本発明の態様では、プラグインコンポーネント３０が、所要のキーストアファイル内に複数のクライアント証明書認証情報を自動的に保存するように構成されていることを想定する。プラグインコンポーネント３０は、１つのキーストアファイル内に、または複数のキーストアファイル内に、複数のクライアント証明書認証情報を選択的に保存してもよい。プラグインコンポーネント３０は、特定のキーストアファイル内に、または必要に応じて複数のキーストアファイル内に、複数のクライアント証明書認証情報を保存できる。
【００３８】
サーバコンピュータ１４に対するクライアントコンピュータ１２の単一認証では、複数のキーストアファイル内に鍵対の共通のセットを登録してもよい。これは、使用者２６がキーストアファイルをエクスポートしなければならず、その後、別のサーバ内に複数のクライアント証明書認証情報をインポートしなければならないという要件を回避する。この機能の向上は、互いに異なるプログラムサービスを利用して同じ暗号証明書認証情報を取り出すアプリケーションにとって重要である。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、最終の使用者２６に鍵対または他の証明書認証情報を手動でインポートとエクスポートすることを要求しない。またプラグインコンポーネント３０を有するクライアントウェブブラウザ２８は、サーバソフトウェアアプリケーション３４と証明書サーバ４４に通信しており、それによって、クライアントコンピュータ１２の認証後には、適切なキーストアファイル内に、または複数のキーストアファイル内に、複数のクライアント証明書認証情報を保存するのに使用者２６も手入力作業も必要としないようになっていることを想定する。
【００３９】
本発明の一実施形態では、暗号化されたキーストアファイルは、暗号鍵と証明書とに対する保存場所である。暗号化されたキーストアファイルは、それぞれ互いに異なるインタフェースを実現する互いに異なるエントリを管理してもよい。プラグインコンポーネント３０が、複数のクライアント証明書認証情報を、暗号化されたキーストアファイルの方向に向かって押すとき、システム内で利用可能な特定のキーストアファイルの種類の最も好ましい実施態様を戻すことによって達成されると想定される。
【００４０】
本発明の他の態様では、暗号化されたキーストアファイルの中に複数のクライアント証明書認証情報を保存するためにデフォルトインプリメンテーションを利用することを想定する。クライアントウェブブラウザ２８のプラグインコンポーネント３０は、クライアン
トコンピュータ１２上に空いている暗号化されたキーストアファイルを生成するように構成されている。あるいは、空いている暗号化されたキーストアファイルを、クライアントウェブブラウザ２８のメモリ内に生成してもよい。
【００４１】
本明細書に示した詳細は、あくまで本発明の実施形態についての説明に役立つ議論を行うために、一例として示したに過ぎず、本発明の原理と概念的見地についての最も有用でかつ容易に理解される説明と考えられるものを提供するために提示している。この点について、本発明の基本的な理解のために必要である更なる詳細を示す試みは行っておらず、図面と合わせて説明を読めば、本発明の幾つかの形態を実際問題としてどのように具体化すればよいかについて当業者に明らかになる。
【特許請求の範囲】
【請求項１】
クライアントウェブブラウザ（２８）を介して、キーストアファイルに複数のクライアント証明書認証情報を保存する認証保存方法であって、前記認証保存方法は、
前記クライアントウェブブラウザ（２８）を介してクライアントコンピュータ（１２）とサーバコンピュータ（１４）の間の安全なデータ転送リンクを確立するリンク確立ステップ（Ｓ１００）であって、前記クライアントウェブブラウザ（２８）は、前記リンク確立ステップのプロセスの間に前記キーストアファイルと鍵対とを生成するプラグインソフトウェアコンポーネント（３０）を有することと；
前記クライアントコンピュータ（１２）上で、前記鍵対からの公開鍵を有する証明書要求を生成する要求生成ステップ（Ｓ１２０）と；
前記証明書要求に署名するように構成される証明書サーバ（４４）に、前記証明書要求を送信する要求送信ステップと；
署名された証明書要求である署名証明書要求（４６）を、前記クライアントウェブブラウザ（２８）上で受信する要求受信ステップと；
前記署名証明書要求（４６）に関連する複数の前記クライアント証明書認証情報を、前記キーストアファイル内に保存する保存ステップ（Ｓ１４０）と
を有することを特徴とする、認証保存方法。
【請求項２】
前記クライアント証明書認証情報は、電子証明書、秘密鍵、公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する、
請求項１記載の認証保存方法。
【請求項３】
前記リンク確立ステップは、前記クライアントウェブブラウザ（２８）を介して前記サーバコンピュータ（１４）にクライアント身元確認情報を提供して、前記サーバコンピュータ（１４）を用いた多元的認証過程の完了に成功するように使用者に要求する、
請求項１記載の認証保存方法。
【請求項４】
前記プラグインソフトウェアコンポーネント（３０）は、前記サーバコンピュータ（１４）から前記クライアントウェブブラウザ（２８）に送信されたブラウザ実行コードである、
請求項１記載の認証保存方法。
【請求項５】
前記サーバコンピュータ（１４）は、セキュアソケットレイヤの仮想専用ネットワークである、
請求項１記載の認証保存方法。
【請求項６】
前記サーバコンピュータ（１４）は、前記クライアントコンピュータ（１２）に通信するサーバソフトウェアアプリケーションをホストする、
請求項１記載の認証保存方法。
【請求項７】
前記サーバソフトウェアアプリケーションは、前記証明書要求または前記署名証明書要求（４６）を、送受信するように構成されている、
請求項６記載の認証保存方法。
【請求項８】
前記プラグインソフトウェアコンポーネント（３０）は、複数のキーストアファイルを生成するように構成されている、
請求項１記載の認証保存方法。
【請求項９】
前記証明書サーバ（４４）は、前記クライアントコンピュータ（１２）と前記サーバコ
ンピュータ（１４）とから遠く離れた認証機関である、
請求項１記載の認証保存方法。
【請求項１０】
前記プラグインソフトウェアコンポーネント（３０）は、前記署名証明書要求（４６）に関連する複数の前記クライアント証明書認証情報を、複数の前記キーストアファイル内に選択的に保存するように構成されている、
請求項８記載の認証保存方法。
【請求項１１】
前記キーストアファイルは、
マイクロソフト暗号ＡＰＩキーストアと；
ＪＡＶＡ（登録商標）キーストアと；
アップルキーストアとＮＳＳキーストアと
からなる群から選択される、
請求項１記載の認証保存方法。
【請求項１２】
前記プラグインソフトウェアコンポーネント（３０）は、前記クライアントウェブブラウザ（２８）を確認して、前記クライアントウェブブラウザ（２８）の符号化ライブラリに関連する前記キーストアファイル内に複数の前記クライアント証明書認証情報を保存するように構成されている、
請求項１記載の認証保存方法。
【請求項１３】
前記データ転送リンクを達成する前に、前記クライアントコンピュータ（１２）が正当な身元と、前記サーバコンピュータ（１４）との接続とを確立することに呼応して、前記キーストアファイルと前記鍵対とは、発生する、
請求項１記載の認証保存方法。
【請求項１４】
複数のクライアント証明書認証情報を保存する認証保存システムであって、前記認証保存システムは、
クライアントコンピュータ（１２）とサーバコンピュータ（１４）の間の安全なデータ転送リンクを確立するように構成された、前記クライアントコンピュータ（１２）上のクライアントウェブブラウザ（２８）と；
前記クライアントウェブブラウザ（２８）によって生成される複数のキーストアファイルと；
前記クライアントコンピュータ（１２）によって生成された証明書要求を受信し、前記証明書要求に署名するように構成された証明書サーバ（４４）と；
鍵対を生成するために前記クライアントウェブブラウザ（２８）によって処理される予定のプラグインソフトウェアコンポーネント（３０）であって、前記プラグインソフトウェアコンポーネント（３０）は、複数の前記キーストアファイルからの少なくとも１つのキーストアファイル内に、複数の前記クライアント証明書認証情報を選択的に保存するように構成されていることと
を有することを特徴とする、認証保存システム。
【請求項１５】
複数の前記クライアント証明書認証情報は、電子証明書、クライアント秘密鍵、クライアント公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する、
請求項１４記載の認証保存システム。
【請求項１６】
前記データ転送リンクの確立は、前記サーバコンピュータ（１４）を用いた多元的認証過程の完了に成功するように前記クライアントコンピュータ（１２）に要求する、
請求項１４記載の認証保存システム。
【請求項１７】
前記証明書サーバ（４４）は、前記クライアントコンピュータ（１２）と前記サーバコンピュータ（１４）とから遠く離れた認証機関である、
請求項１４記載の認証保存システム。
【請求項１８】
署名された証明書要求としての署名証明書要求（４６）の受信に呼応して、前記クライアントウェブブラウザ（２８）は、電子証明書を生成する、
請求項１４記載の認証保存システム。
【請求項１９】
前記プラグインソフトウェアコンポーネント（３０）は、前記サーバコンピュータ（１４）から前記クライアントウェブブラウザ（２８）に送信されたブラウザ実行コードである、
請求項１４記載の認証保存システム。
【請求項１】
クライアントウェブブラウザ（２８）を介して、キーストアファイルに複数のクライアント証明書認証情報を保存する認証保存方法であって、前記認証保存方法は、
前記クライアントウェブブラウザ（２８）を介してクライアントコンピュータ（１２）とサーバコンピュータ（１４）の間の安全なデータ転送リンクを確立するリンク確立ステップ（Ｓ１００）であって、前記クライアントウェブブラウザ（２８）は、前記リンク確立ステップのプロセスの間に前記キーストアファイルと鍵対とを生成するプラグインソフトウェアコンポーネント（３０）を有することと；
前記クライアントコンピュータ（１２）上で、前記鍵対からの公開鍵を有する証明書要求を生成する要求生成ステップ（Ｓ１２０）と；
前記証明書要求に署名するように構成される証明書サーバ（４４）に、前記証明書要求を送信する要求送信ステップと；
署名された証明書要求である署名証明書要求（４６）を、前記クライアントウェブブラウザ（２８）上で受信する要求受信ステップと；
前記署名証明書要求（４６）に関連する複数の前記クライアント証明書認証情報を、前記キーストアファイル内に保存する保存ステップ（Ｓ１４０）と
を有することを特徴とする、認証保存方法。
【請求項２】
前記クライアント証明書認証情報は、電子証明書、秘密鍵、公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する、
請求項１記載の認証保存方法。
【請求項３】
前記リンク確立ステップは、前記クライアントウェブブラウザ（２８）を介して前記サーバコンピュータ（１４）にクライアント身元確認情報を提供して、前記サーバコンピュータ（１４）を用いた多元的認証過程の完了に成功するように使用者に要求する、
請求項１記載の認証保存方法。
【請求項４】
前記プラグインソフトウェアコンポーネント（３０）は、前記サーバコンピュータ（１４）から前記クライアントウェブブラウザ（２８）に送信されたブラウザ実行コードである、
請求項１記載の認証保存方法。
【請求項５】
前記サーバコンピュータ（１４）は、セキュアソケットレイヤの仮想専用ネットワークである、
請求項１記載の認証保存方法。
【請求項６】
前記サーバコンピュータ（１４）は、前記クライアントコンピュータ（１２）に通信するサーバソフトウェアアプリケーションをホストする、
請求項１記載の認証保存方法。
【請求項７】
前記サーバソフトウェアアプリケーションは、前記証明書要求または前記署名証明書要求（４６）を、送受信するように構成されている、
請求項６記載の認証保存方法。
【請求項８】
前記プラグインソフトウェアコンポーネント（３０）は、複数のキーストアファイルを生成するように構成されている、
請求項１記載の認証保存方法。
【請求項９】
前記証明書サーバ（４４）は、前記クライアントコンピュータ（１２）と前記サーバコ
ンピュータ（１４）とから遠く離れた認証機関である、
請求項１記載の認証保存方法。
【請求項１０】
前記プラグインソフトウェアコンポーネント（３０）は、前記署名証明書要求（４６）に関連する複数の前記クライアント証明書認証情報を、複数の前記キーストアファイル内に選択的に保存するように構成されている、
請求項８記載の認証保存方法。
【請求項１１】
前記キーストアファイルは、
マイクロソフト暗号ＡＰＩキーストアと；
ＪＡＶＡ（登録商標）キーストアと；
アップルキーストアとＮＳＳキーストアと
からなる群から選択される、
請求項１記載の認証保存方法。
【請求項１２】
前記プラグインソフトウェアコンポーネント（３０）は、前記クライアントウェブブラウザ（２８）を確認して、前記クライアントウェブブラウザ（２８）の符号化ライブラリに関連する前記キーストアファイル内に複数の前記クライアント証明書認証情報を保存するように構成されている、
請求項１記載の認証保存方法。
【請求項１３】
前記データ転送リンクを達成する前に、前記クライアントコンピュータ（１２）が正当な身元と、前記サーバコンピュータ（１４）との接続とを確立することに呼応して、前記キーストアファイルと前記鍵対とは、発生する、
請求項１記載の認証保存方法。
【請求項１４】
複数のクライアント証明書認証情報を保存する認証保存システムであって、前記認証保存システムは、
クライアントコンピュータ（１２）とサーバコンピュータ（１４）の間の安全なデータ転送リンクを確立するように構成された、前記クライアントコンピュータ（１２）上のクライアントウェブブラウザ（２８）と；
前記クライアントウェブブラウザ（２８）によって生成される複数のキーストアファイルと；
前記クライアントコンピュータ（１２）によって生成された証明書要求を受信し、前記証明書要求に署名するように構成された証明書サーバ（４４）と；
鍵対を生成するために前記クライアントウェブブラウザ（２８）によって処理される予定のプラグインソフトウェアコンポーネント（３０）であって、前記プラグインソフトウェアコンポーネント（３０）は、複数の前記キーストアファイルからの少なくとも１つのキーストアファイル内に、複数の前記クライアント証明書認証情報を選択的に保存するように構成されていることと
を有することを特徴とする、認証保存システム。
【請求項１５】
複数の前記クライアント証明書認証情報は、電子証明書、クライアント秘密鍵、クライアント公開鍵、証明書チェーン、および複数のクライアント身元確認情報を有する、
請求項１４記載の認証保存システム。
【請求項１６】
前記データ転送リンクの確立は、前記サーバコンピュータ（１４）を用いた多元的認証過程の完了に成功するように前記クライアントコンピュータ（１２）に要求する、
請求項１４記載の認証保存システム。
【請求項１７】
前記証明書サーバ（４４）は、前記クライアントコンピュータ（１２）と前記サーバコンピュータ（１４）とから遠く離れた認証機関である、
請求項１４記載の認証保存システム。
【請求項１８】
署名された証明書要求としての署名証明書要求（４６）の受信に呼応して、前記クライアントウェブブラウザ（２８）は、電子証明書を生成する、
請求項１４記載の認証保存システム。
【請求項１９】
前記プラグインソフトウェアコンポーネント（３０）は、前記サーバコンピュータ（１４）から前記クライアントウェブブラウザ（２８）に送信されたブラウザ実行コードである、
請求項１４記載の認証保存システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１１−５１５９６１（Ｐ２０１１−５１５９６１Ａ）
【公表日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願番号】特願２０１１−５００９７２（Ｐ２０１１−５００９７２）
【出願日】平成２１年３月２０日（２００９．３．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３７７７０
【国際公開番号】ＷＯ２００９／１１７６３８
【国際公開日】平成２１年９月２４日（２００９．９．２４）
【出願人】（５１０２５２５８６）セキュアオース コーポレイション (1)
【氏名又は名称原語表記】ＳＥＣＵＲＥＡＵＴＨ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願日】平成２１年３月２０日（２００９．３．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３７７７０
【国際公開番号】ＷＯ２００９／１１７６３８
【国際公開日】平成２１年９月２４日（２００９．９．２４）
【出願人】（５１０２５２５８６）セキュアオース コーポレイション (1)
【氏名又は名称原語表記】ＳＥＣＵＲＥＡＵＴＨ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]