JP2004048742A - ベース暗号サービスプロバイダ（ｃｓｐ）の方法および装置 - Google Patents
ベース暗号サービスプロバイダ（ｃｓｐ）の方法および装置 Download PDFInfo
- Publication number
- JP2004048742A JP2004048742A JP2003180213A JP2003180213A JP2004048742A JP 2004048742 A JP2004048742 A JP 2004048742A JP 2003180213 A JP2003180213 A JP 2003180213A JP 2003180213 A JP2003180213 A JP 2003180213A JP 2004048742 A JP2004048742 A JP 2004048742A
- Authority
- JP
- Japan
- Prior art keywords
- cryptographic
- function
- logic
- smart card
- support
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
Abstract
【課題】暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成可能なインタフェースロジックのための装置および方法を提供すること。
【解決手段】インタフェースロジックは、少なくとも１つの管理機能を暗号提供ロジックに提供する。その管理機能は、次の４つの管理機能、すなわち識別管理機能、ファイル管理機能、コンテナ管理機能、および暗号法管理機能のうち少なくとも１つを含んでいる。
【選択図】 図１
【解決手段】インタフェースロジックは、少なくとも１つの管理機能を暗号提供ロジックに提供する。その管理機能は、次の４つの管理機能、すなわち識別管理機能、ファイル管理機能、コンテナ管理機能、および暗号法管理機能のうち少なくとも１つを含んでいる。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、一般に、コンピューティングデバイスに関し、より詳細には、例えば、異なるタイプのスマートカードなど、異なるタイプのポータブルトークンデバイスを、コンピューティングデバイスに動作可能にインタフェースする際に使用する方法および装置に関する。
【０００２】
【従来の技術】
暗号法は、通例、データが安全に記憶され、かつ／または伝送されるような方法で、データを認証し、符号化し、または暗号化／解読するために利用されている。暗号法は、コンピュータおよびネットワークの数、サイズおよび複雑性が増すにつれ、より一層一般的なものになっている。
【０００３】
一例として、パーソナルコンピュータ（ＰＣ）などのコンピューティングデバイスにおいては、一般に、公開鍵／秘密鍵のペアを使用することにより、通信当事者間で交換されるデータの非対称暗号化を行う。非対称暗号化は、公開鍵暗号化アルゴリズムを使用している。公開鍵アルゴリズムは、２つの異なる鍵（鍵ペアとして知られる）、すなわち、公開鍵と秘密鍵を使用する。これらの２つの鍵は、一般に、それらを数学的に関係付けるきわめて大きな素数から導出される。しかし、実際には、一方の鍵をもう一方から導出することは不可能である。それらの名前が示唆するように、公開鍵は公開され、一方、秘密鍵は秘密にされる。一般的な静的マシンに集中したＰＣ環境においては、秘密鍵が、それを生成したＰＣから離れることは絶対にない場合がある。
【０００４】
鍵の一方で暗号化された情報（すなわちデータ）は、鍵のもう一方でのみ解読することができる。したがって、例えば、秘密鍵で暗号化されたデータは公開鍵でのみ、逆に、公開鍵で暗号化されたデータは秘密鍵でのみ解読することができる。
【０００５】
さらなる安全策として、通信セッションの間、セッション鍵を使用することができる。セッション鍵は、基本的に、通信当事者間で共用される一時的な秘密鍵または秘密である。受信者は、セッション鍵を解読すると、暗号化されているデータを解読することができる。解読したメッセージの保全性は、そのメッセージをハッシュしてメッセージダイジェストを生成し、そのダイジェストの値を、送信者が計算して暗号化メッセージ中に含めたダイジェストと比較することによって確認することができる。
【０００６】
このような暗号法技術に関連する問題の１つは、例えば、通信当事者の公開鍵の１つであると称する公開鍵を不正に差し出すことによって、第三者が通信当事者の一方のなりすましを図る可能性があることである。その通信当事者に宛てられた、その不正な公開鍵によって暗号化されたメッセージまたはハッシュはどれも、その第三者が持っている秘密鍵で解読できると考えられる。
【０００７】
この問題およびその他の問題に対処するために、通信当事者はディジタル証明書を利用することができる。ディジタル証明書は、例えばＶｅｒｉＳｉｇｎ，Ｉｎｃ．など、認証局（ＣＡ）と呼ばれる信頼のおける機関またはエンティティが発行する資格認定書である。この資格認定書は、一般に、公開鍵、およびその証明書の対象者（すなわち、適用される通信当事者）を識別するデータを含む。証明書は、通常、ＣＡがその証明書の対象者を確認し、また、証明書とともに含まれる公開鍵がその対象者に所属するものであることを確認した後でのみ、ＣＡによって発行される。証明書はまた、その証明書が変更されたり偽造されたりしたものではないことを保証するため、ＣＡの公開鍵で署名された、証明書の内容のダイジェストも含む。
【０００８】
ＣＡはまた、本質的に信頼できる自己署名証明書、すなわちルート証明書を提供することもできる。ＣＡは、他のＣＡの階層によってそれ自身を証明することができる。このような情報は、通常、証明書内に含まれている。ディジタル証明書を使って文書およびソフトウェアに署名する場合、この情報が、信頼関係を確立するためにユーザに表示することができる安全かつ確認可能なフォームで、署名された項目とともに記憶される。
【０００９】
長い間には、ディジタル証明書がＰＣ上に蓄積しがちになる。これらのディジタル証明書は、通常、証明書ストアに収集される。一般に、ユーザが、証明書ストア内でディジタル証明書を記憶し、検索し、削除し、列挙し、確認し、または保持することができるようにするツールが、アプリケーションプログラミングインタフェース（ＡＰＩ）機能として提供されている。
【００１０】
これを考慮して、ワシントン州、レッドモンドのＭｉｃｒｏｓｏｆｔ社は、汎用および専用コンピュータ、ＰＣ、ポータブルデバイスなどを含めた、様々な「マシン」で使用するためのソフトウェア、オペレーティングシステム、およびその他のアプリケーションを開発している。Ｍｉｃｒｏｓｏｆｔ社は、暗号サービスを求めるアプリケーションと、このような暗号サービスを提供できるプログラム／デバイスの間の、制御された／拡張可能なインタフェースを提供する暗号ＡＰＩ（以下、「ＣｒｙｐｔｏＡＰＩ」と呼ぶ）を開発した。ＣｒｙｐｔｏＡＰＩ内では、証明書ストア内のディジタル証明書を管理し、また、ディジタル証明書をデータファイルに添付するために使用できるツール（例えば関数）が提供されている。例えば、ＣｒｙｐｔｏＡＰＩは、一般にＣＡによって発行され、もはや有効ではないディジタル証明書が記載された、証明書廃止リスト（ＣＲＬ）を保持している。また、ＣｒｙｐｔｏＡＰＩは、信頼のおけるエンティティが署名した項目を識別する、証明書信頼リスト（ＣＴＬ）もサポートする。証明書ストア内の様々なディジタル証明書、ＣＲＬおよびＣＴＬは、通常、例えばディスクファイルやシステムレジストリなど、マシン内の不揮発性メモリ内に保持されている。
【００１１】
要求された暗号サービスを提供することができる暗号プログラム／デバイスは、マシンに追加されて必要な一意の暗号トークンを提供する、汎用および／または専用のハードウェア／ソフトウェアを含むことができる。したがって、例えば、ＣｒｙｐｔｏＡＰＩは、新規／追加の暗号デバイス／トークンがマシンに追加されることを可能にし、要求しているアプリケーションと追加された暗号デバイス／トークン間のインタフェースとして動作する。このタイプのＡＰＩ機能／インタフェースはよく知られており、例えば、それをはるかに詳細に記載している１９９７年１１月１８日にＳｐｉｅｓらに対して発行された文献もある（例えば、特許文献１参照）。
【００１２】
上述のＡＰＩ機能／インタフェースは、基本的に、暗号デバイスが所定の場所に固定され、常に利用可能であり、ローカルマシンによってのみ使用されることを前提としているため、静的マシンに集中したトークンを使った場合にはうまく動作する傾向がある。しかし、トークンのいくつかがポータブルである場合には、ＡＰＩ機能／インタフェースは必ずしも必要とするトークンの位置を突き止めることができない。
【００１３】
【特許文献１】
米国特許第５，６８９，５６５号明細書
【００１４】
【発明が解決しようとする課題】
その結果、最近のスマートカード（ＳＣ）、およびその他のタイプのポータブルトークン搬送デバイスおよび／またはリムーバブル処理デバイスの人気とともに、設計者は、特定のＳＣなどがＣｒｙｐｔｏＡＰＩで動作できるようにする特定のフォームのインタフェースロジックを提供することが要求されるようになっている。これによっていくつかの問題が生じた。例えば、ＰＣまたはその他の同様のコンピューティングデバイスは、異なるタイプのＳＣをサポートできる必要がある場合には、その異なるＳＣのそれぞれについて、正しいインタフェースロジック、例えばソフトウェアを保持することが必要になる。さらに、多くの場合において明らかになっているように、インタフェースロジックは、構築および設計するのが非常に複雑な場合がある。これらおよびその他の理由から、ポータブルトークンメカニズムおよび／またはその他の同様のリムーバブル／非リムーバブル処理デバイスを、様々な形態のコンピューティングデバイスおよび／または機器内のロジックをサポートする、特定の暗号法に動作可能に結合するための、改良された方法および装置の必要がある。
【００１５】
【課題を解決するための手段】
上述およびその他のニーズは、例えば、本発明の特定の実施形態による装置によって満たされる。その装置は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを含む。このインタフェースロジックは、少なくとも１つの管理機能を暗号提供ロジックに提供する。管理機能は、次の４種類の管理機能、すなわち識別管理機能、ファイル管理機能、コンテナ管理機能、暗号法管理機能のうち少なくとも１つを含む。
【００１６】
その他の実施形態によれば、ある方法が提供される。その方法は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを提供するステップ、および、暗号提供ロジックに動作可能に結合された場合に、識別確認アクティビティ、ファイルアクセスアクティビティ、コンテナアクセスアクティビティ、および暗号アルゴリズムアクティビティを含むアクティビティグループから選択した、少なくとも１つのアクティビティを実行するように、インタフェースロジックを構成するステップを含む。
【００１７】
さらに別の実施形態では、コンピュータ可読媒体の権利を主張する。コンピュータ実行可能命令は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを確立するステップ、および、識別サポート機能、ファイルアクセスサポート機能、コンテナアクセスサポート機能、および暗号法サポート機能を含むサポート機能グループから選択された少なくとも１つのサポート機能を、インタフェースロジックに確立させるステップを含む動作を、コンピューティングまたはその他の同様のデバイスに実行させることができるコンピュータ可読媒体によって提供される。
【００１８】
本発明の様々な方法および構成を、添付の図面を参照しながら以下の詳細な説明を読むことによって、より完全に理解することができるであろう。
【００１９】
【発明の実施の形態】
概略
以下のセクションでは、様々なコンピューティングデバイスなどにおいて使用するための、例示的な改良された結合／インタフェーススキームを説明する。本発明の特定の態様によれば、この例示的結合／インタフェーススキームを、ハードウェア、ファームウェア、ソフトウェアまたはそれらのいずれかの組合せを含むロジックとして実装することができる。結果として得られるロジックは、例えば、複数の異なるポータブルトークンデバイスおよび／またはその他の同様のリムーバブル／非リムーバブル処理デバイスに、「基礎」レベルのサポートを提供するように構成することができる。その一例がスマートカードである。
【００２０】
以下の説明の多くでは、Ｍｉｃｒｏｓｏｆｔ（登録商標）社のＣｒｙｐｔｏＡＰＩに基づくオペレーティングシステムのサブコンポーネントおよび関連モジュールの既存の特徴を考慮しているが、本発明の範囲はそれよりもはるかに広く、それらに限定されるものではない。例えば、結合／インタフェーススキームおよび技術は、静的トークンとポータブルトークンの両方をサポートする環境における、様々な開発者／ベンダ、および／または彼らの製品の機能、責任、および／または関連する能力に関して、役立つ境界線を定義する。したがって、例示的方法および装置はポータブルであり、またはそうでない場合には、その他の環境、マシン、および／またはオペレーティングシステムに適合可能である。
【００２１】
例示的コンピューティングデバイス構成
図１は、本発明の特定の例示的実施形態による、改良された結合／インタフェーススキームおよび技術に適し、かつ／またはそれらをサポートするコンピュータ１３０の一般的な例を示す例示的構成図である。様々なタイプのコンピューティングデバイスが、これらのスキームおよび技術から恩恵を得ることができる。したがって、「マシン」という用語を、それらのスキームおよび技術の全てまたは一部を実施することが可能な、いずれかのタイプのデバイスまたは機器を表すためにも使用することがしばしばある。
【００２２】
図１を参照すると、コンピュータ１３０は、１つまたは複数の処理装置１３２、システムメモリ１３４、および、システムメモリ１３４を含めて、様々なコンポーネントをプロセッサ１３２に結合するバス１３６を含む。バス１３６は、様々なバスアーキテクチャのいずれかを使った、メモリバスまたはメモリコントローラ、周辺バス、アクセラレイティッドグラフィックスポート、およびプロセッサまたはローカルバスを含めた、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。システムメモリ１３４は、読出し専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などに、コンピュータ１３０内のエレメント間の情報の転送を援助する、基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２は、ＲＯＭ１３８に記憶されている。
【００２３】
コンピュータ１３０は、ハードディスク（図示せず）からの読出し、およびそれへの書込みのためのハードディスクドライブ１４４、リムーバブル磁気ディスク１４８からの読出し、およびそれへの書込みのための磁気ディスクドライブ１４６、および、ＣＤ−ＲＯＭやその他の光媒体などのリムーバブル光ディスク１５２からの読出し、およびそれへの書込みのための光ディスクドライブ１５０をさらに含む。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０は、ＳＣＳＩインタフェース１５４または特定のその他の適切なインタフェースによって、バス１３６に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストレージを、コンピュータ１３０に提供する。本明細書に記載の例示的環境は、ハードディスク、リムーバブル磁気ディスク１４８、およびリムーバブル光ディスク１５２を利用しているが、当業者は、例示的動作環境においては、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など、コンピュータがアクセス可能なデータを記憶することができるその他のタイプのコンピュータ可読媒体も使用できることを理解されたい。
【００２４】
ハードディスク、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０上には、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、およびプログラムデータ１６４を含めて、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード１６６およびポインティングデバイス１６８などの入力デバイスを介して、コマンドおよび情報をコンピュータ１３０に入力することができる。その他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらおよびその他の入力デバイスは、バス１３６に結合されたインタフェース１７０を介して、処理装置１３２に接続される。モニタ１７２またはその他のタイプの表示デバイスも、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続される。パーソナルコンピュータは、一般に、モニタに加えて、スピーカおよびプリンタなど、その他の周辺出力デバイス（図示せず）を含む。
【００２５】
コンピュータ１３０は、一般に、リモートコンピュータ１７６などの１台または複数のリモートコンピュータへの論理接続を使った、ネットワーク化された環境で動作する。リモートコンピュータ１７６は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードであってよく、図１にはメモリストレージデバイス１７８しか示していないが、一般に、コンピュータ１３０に関連して上記に説明したエレメントの多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１８０および広域ネットワーク（ＷＡＮ）１８２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいては一般的である。
【００２６】
コンピュータ１３０は、ＬＡＮネットワーキング環境で使用される場合は、ネットワークインタフェースまたはアダプタ１８４を介してローカルネットワーク１８０に接続される。コンピュータ１３０は、ＷＡＮネットワーキング環境で使用される場合は、一般に、モデム１８６、または、インターネットなどの広域ネットワーク１８２を介して通信を確立するためのその他の手段を含む。モデム１８６は内蔵でも外付けでもよく、シリアルポートインタフェース１５６を介してバス１３６に接続される。ネットワーク化された環境においては、パーソナルコンピュータ１３０に関連して示すプログラムモジュール、またはそれらの一部を、リモートのメモリストレージデバイスに記憶することができる。図示のネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立するためのその他の手段も使用できることを理解されたい。
【００２７】
一般に、コンピュータ１３０のデータプロセッサは、コンピュータの様々なコンピュータ可読記憶媒体中に、異なる時間に記憶された諸命令によってプログラムされる。一般に、プログラムおよびオペレーティングシステムは、例えばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布され、それらから、コンピュータの補助メモリ中にインストールまたはロードされる。実行時、それらは、少なくとも一部が、コンピュータの主電子メモリ中にロードされる。本明細書に記載の発明は、マイクロプロセッサまたはその他のデータプロセッサと関連して、下記に説明するステップを実施するための命令またはプログラムを含む場合の、これらおよびその他の様々なタイプのコンピュータ可読記憶媒体を含む。本発明はまた、下記に記載の方法および技術に従ってプログラムされている場合のコンピュータ自体も含む。
【００２８】
説明のために、本明細書では、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントを別個のブロックとして説明するが、このようなプログラムおよびコンポーネントは、様々な時点で、コンピュータの異なるストレージコンポーネントに存在し、また、コンピュータのデータプロセッサによって実行されることを理解されたい。
【００２９】
トークンの可搬性、およびアプリケーションプログラム１６０をサポートする、関連する暗号機能をサポートするために、コンピュータ１３０は、少なくとも１つのポータブルトークンインタフェースをさらに含む。例えば、適用可能なトークンデータ／命令で符号化されている場合には、磁気ディスク１４８または光ディスク１５２をトークンキャリアまたはデバイスとみなすことができる。しかし、さらに将来は、ポータブルトークンインタフェースが、コンピュータ１３０への追加ハードウェアの結合を含む可能性がある。したがって、図示のように、例えば、スマートカードリーダ２００を、シリアルポート１５６などのポートを介して、バス１３６に接続することができる。スマートカードリーダ２００は、その他の入出力デバイスと同様に、アプリケーションプログラムおよび／またはその他のモジュールによってサポートされる。スマートカードリーダ２００は、スマートカード２０２を受けて、スマートカード２０２を処理装置１３２に動作可能に結合するように構成される。スマートカードリーダ２００は、複数のスマートカードをサポートすることができる。当業者は、その他のタイプ／形態のポータブルトークン、および／またはその他の同様のリムーバブル／非リムーバブル処理メカニズムが、その他のインタフェースデバイスを利用できることを理解されよう。
【００３０】
さらなる例によれば、適用可能であれば、ユニバーサルシリアルバス（ＵＳＢ）ポート２０４をバス１３６に結合して、スマートカードリーダおよび／またはその他のタイプのポータブルトークンデバイス２０６をサポートすることができる。ポータブルトークンデバイスの基本的概念は、暗号機能をサポートするために必要とされる場合には、ユーザがそれを１つまたは複数のコンピュータシステムに供給できるということである。リムーバブル／非リムーバブル処理メカニズムの基本的概念も同じであり得るが、ただし、製造者またはその他の技術者／管理者によってデバイスまたは機器中に構成されたスマートカードの場合のように、特定の実施形態ではそのメカニズムを実質的に永久的に構成することができる点が異なる。一例として、セットトップボックスまたはその他のデバイス内に埋め込まれ、通常は消費者が取り外すことはない加入者カードが挙げられる。
【００３１】
例示的ポータブルトークンおよび／またはその他の同様の処理デバイス
図２は、例示的スマートカード２０２を示す構成図である。図示のように、スマートカード２０２は、オンボードコントローラまたはプロセッサ２０６に結合されたコネクタ２０４を含む。プロセッサ２０６は、さらにオンボードメモリ２０８に結合されている。メモリ２０８は、一般に、データの損失なしにスマートカード２０２をマシンからマシンに移動させることが可能な、不揮発性メモリである。プロセッサ２０６は、スマートカード２０２に電源が投入されると、メモリ２０８および／またはコンピュータ１３０によって与えられる命令に応答可能になる。
【００３２】
この構成の場合、暗号鍵にかなりのセキュリティを提供するように、スマートカードを構成することができる。ユーザがスマートカード２０２によって提供されるサービスを起動、またはそれらにアクセスしようとすると、さらなるセキュリティまたは識別データ（例えば、個人識別番号（ＰＩＮ）またはストリング、個人的および／またはその他の生物測定学上の情報／データ）をコンピュータ１３０に入力するようにユーザに要求することにより、さらなるセキュリティを提供することができる。例えば、カード所有者は、ＰＩＮを入力して秘密鍵を起動すること、または指紋をスキャンさせることが要求される場合がある。例えばトークンキャリアとして、スマートカード２０２は、好ましくは、少なくとも１組の非対象鍵ペアを保持する。対象鍵は、コンピュータ１３０のより強力な処理装置１３２によって処理されることが好ましい。
【００３３】
スマートカードの開発者は、通常、自分が望むように、自由にスマートカードを開発／プログラムし、また、以前に定義されたインタフェースは複雑でエラーを発生し易いため、これらのスマートカードへのインタフェースにおいて問題が発生する場合がある。現在、スマートカードには、物理インタフェースレベルを超えるスタンダードはほとんどない。カリフォルニア州、レッドウッドシティのＲＳＡ研究所から入手可能な、公開鍵暗号法スタンダード＃１１：暗号トークンインタフェーススタンダードが、現在、ポータブルトークンの使用を規定するためのドラフト段階にある。しかし、現在のドラフト中で提案されている解決策／インタフェースは、本明細書で記載しているような、様々なオブジェクトおよびメソッドの呼出し技術を使ったクリーン／汎用インタフェースを提供しない。
【００３４】
さらに、インタフェースレベルを超える指定スタンダードはどれも、それぞれが自分達自身の要件、スタンダードおよびプラクティスを持っている可能性があるスマートカードベンダにとっては逆効果であるというのが、一般的なコンセンサスであるように思われる。
【００３５】
本発明の特定の態様によれば、このような様々なデバイスの製造者および実装者のプランおよび／または要望が、非常に必要とされ、ロバストに実装可能な結合／インタフェーススキーマおよび技術によって考慮され、サポートされる。本発明の特定のさらなる態様によれば、必要不可欠なインタフェースをサポートするための重要なコードを開発する負担は、基本的に、オペレーティングシステムおよび／またはそのサブコンポーネントの開発者にシフトされている。
【００３６】
従来のソフトウェアアーキテクチャソリューション
図３を参照する。図３は、１つまたは複数のアプリケーション３０２と、１つまたは複数のスマートカード３０８ａ〜ｎ間のインタフェースを提供するために実装された、従来のソフトウェアアーキテクチャソリューション３００の例示的な一部を示す構成図である。
【００３７】
この例では、呼び出しているアプリケーション３０２とスマートカード３０８ａ〜ｎの間の従来のインタフェースは、呼び出しているアプリケーション３０２をサポートするように動作可能に構成された暗号ＡＰＩ３０４を含む。インタフェースは、１つまたは複数の暗号サービスプロバイダ（ＣＳＰ）３０６ａ〜ｎをさらに含む。この例では、一意の異なるスマートカード３０８ａ〜ｎのそれぞれについて、対応するＣＳＰ３０６ａ〜ｎがある。
【００３８】
従来、各スマートカード３０８ａ〜ｎは特定のデータおよび／またはデータ交換、および関数の呼出しを必要とするため、信頼できるＣＳＰ３０６ａ〜ｎを開発することは、きわめて困難であることがわかっている。様々なソフトウェア開発者またはその他の同様のベンダは、通常、インタフェース内の彼らそれぞれのロジックに対する責任を負うため、そのような努力はさらに複雑化されている。したがって、例えば、図３では、ベンダ１をスマートカード（ＳＣ１）３０８ａおよび対応するＣＳＰ１３０６ａを提供するものとして図示してあり、一方、ベンダ０は暗号ＡＰＩ３０４を提供する。経験により、暗号ＡＰＩ３０４を考慮して、またその他の（おそらくまだ決定されていない）スマートカードリーダ、スマートカード、および対応するＣＳＰも考慮してロバストＣＳＰ１３０６ａを生産するために、ベンダ１に負わされる負担は大きすぎる可能性があることがわかっている。
【００３９】
したがって、インタフェース操作、および様々なスマートカードおよび同様のデバイスの機能を分析した結果、スマートカードベンダに負わされている負担を実質的に低減する、改良された設計が得られた。さらに、本明細書で提示する、結果として得られた結合／インタフェーススキームおよび技術は、複数の専用／限定用途インタフェースではなく、より標準化された、または汎用のインタフェースを提供する。
【００４０】
改良されたソフトウェアアーキテクチャソリューション
図４を参照する。図４は、本発明の特定の例示的実施形態による、改良されたソフトウェアアーキテクチャ４００を示す構成図である。
【００４１】
ここで、ソフトウェアアーキテクチャ４００は、１つまたは複数のスマートカード（ＳＣ）３０８ａ〜ｎおよび／またはその他の同様のデバイスのサービス／機能を要求し、かつ／または使用するように構成可能な、１つまたは複数のアプリケーション３０２を含む。図３に示すように、アプリケーション３０２は、暗号ＡＰＩ３０４に動作可能に結合されている。暗号ＡＰＩ３０４とＳＣ３０８ａ〜ｎの間の動作は、ベースＣＳＰ４０２であり、必要に応じて、１つまたは複数のスマートカード特有モジュール４０４ａ〜ｎである。さらに、この実施形態では、ベースＣＳＰ４０２とともに、１つまたは複数の管理ＡＰＩ４０６が含まれている。
【００４２】
特定の例示的態様によれば、ベースＣＳＰ４０２によって提供される機能には、ＳＣ３０８ａ〜ｎの少なくとも一部に共通である、１つまたは複数のインタフェースサポート機能が含まれる。例として、特定の実施形態では、ベースＣＳＰは、少なくとも４種類の共通インタフェースサポートアクティビティ、すなわち、ＰＩＮ管理、ファイル管理、コンテナ管理、および暗号操作を提供／サポートする。ＳＣ３０８ａ〜ｎのそれぞれは、特定の時点で、このようなアクティビティおよび／またはインタフェース機能を必要とするプロセスに関与するため、これらのインタフェースサポートアクティビティは、「汎用カテゴリ」を表すとみなすことができる。
【００４３】
したがって、図４では、ベースＣＳＰ４０２は、ＰＩＮマネージャ４０８、ファイルマネージャ４１０、コンテナマネージャ４１２、および暗号マネージャ４１４の機能を含む。これらの管理モジュールは、スマートカードベンダがより容易に対話することができ、また恩恵を引き出すことができる、十分に定義されたインタフェースを提供するように構成されている。したがって、本発明の特定の実施形態によれば、ベースＣＳＰ４０２は、暗号機能、および、スマートカードによって提供されるデータストレージ、スマートカードおよびその機能を発見し、それらにアクセスする際のＣｒｙｐｔｏＡＰＩの機能などのその他の機能を動作可能にサポートする、「ミニドライバ」として動作するように構成される。
【００４４】
ＰＩＮマネージャ４０８、ファイルマネージャ４１０、コンテナマネージャ４１２、および／または暗号マネージャ４１４を使って、ベースＣＳＰ４０２は、スマートカード３０８ａ〜ｎが提供できる様々な適用可能な特徴を提示する。暗号ＡＰＩ３０４とスマートカード３０８ａ〜ｎの両方が、それらの開発者やベンダなどに関係なく、ベースＣＳＰ４０２によって提供される定義済みインタフェース機能セットを有する。モジュラーの論理構成においては、追加される新しい／異なるスマートカード３０８ａ〜ｎのそれぞれは、ベースＣＳＰ４０２によって提示された共通機能の使用法をそのときにのみ必要とするだけである。スマートカード３０８ａ〜ｎは、せいぜい、スマートカードロジックとベースＣＳＰ４０２の間で交換された情報を、必要に応じて変換または処理するスマートカード特有モジュールを提供する必要があるだけである。さらに、本発明の特定の実施形態によれば、ベースＣＳＰを、暗号ＡＰＩ３０４の大幅な変更が必要ないように、あるいは全く変更する必要がないように設計することができる。さらに、１つまたは複数のカード管理ＡＰＩ４０６を、スマートカード３０８ａ〜ｎ、および場合によっては暗号ＡＰＩ３０４に、新規／追加サポートを提供するように実装することができる。
【００４５】
ＰＩＮマネージャ４０８は、例えば、ユーザが、自分がスマートカードを使用する認可を受けたユーザであることをスマートカードに納得させるために、必要な情報を入力するログオン操作などの、識別機能をサポートするように構成される。したがって、例えば、特定の実施形態では、ベースＣＳＰが、ユーザを認証するために使用できる、証明書、ＲＳＡ呼出しなど、ユーザのＰＩＮまたはその他の同様の情報の受信／処理をサポートする。一例では、ＰＩＮを使って、カードに対してユーザを認証することができる。カードに対して認証されると、ユーザは、次いで、カード上のＲＳＡ秘密鍵を使って、自分自身をシステムに対して認証させることができる。一般に、ユーザが自分自身をシステムに対して認証させるためには、証明書も必要とされる。したがって、スマートカード上にその証明書を記憶すると便利である。これらおよびその他の様々な信頼のおける認証技術などはよく知られており、したがって、それらについての詳細な説明は本明細書の範囲外である。
【００４６】
したがって、暗号ＡＰＩ３０４が、暗号の関連付けを行い、またはコンテキストを作成することによって、その後、アプリケーション３０２が、スマートカード３０８ａ〜ｎによって提供される暗号機能およびその他の機能を利用できるようにする際に、暗号ＡＰＩ３０４を援助するようにＰＩＮマネージャ４０８を構成することができる。このような機能および／またはその他の機能を遂行するために、ＰＩＮマネージャ４０８は、１つまたは複数のＡＰＩを含むことができる。
【００４７】
本発明の特定の例示的実施形態によれば、ファイルマネージャ４１０は、アクセスメモリ２０８（例えば図２参照）およびその中に提供されているデータファイルおよび／またはファイル構造を発見し、かつ／またはそれらにアクセスする機能を、アプリケーション３０２に提供するように構成される。多くの場合、スマートカード３０８ａ〜ｎは、メモリおよび／またはその中に記憶されているデータファイルのすべてまたは選択された一部に対するそのようなアクセスを、許可／不許可することができる可能性がある。特定の実施形態では、このような構成は、多くのオペレーティングシステムでは一般的な、読出し、書込み、および／または消去の許可など、特定ファイルへのアクセス許可を含むことができる。したがって、このような機能および／またはその他の機能を遂行するために、ファイルマネージャ４１０は、１つまたは複数のＡＰＩを含むことができる。
【００４８】
本発明の特定の実施形態によれば、コンテナマネージャ４１２は、コンテナおよび／またはそれらの内容、あるいは、スマートカード３０８ａ〜ｎに関連づけられ、少なくとも一時的にメモリ２０８中で保持される、その他のコンテナ関連の情報について、発見、アクセス、および／または制御を行うように構成される。本明細書で使用しているように、コンテナという用語は、一般に、代表的にはオブジェクトベースまたはその他の同様のロジックの設計（例えば、ソフトウェアプログラミング方法）において提供される、１つまたは複数のオブジェクトを指す。コンテナは、一般に、１つまたは複数のオブジェクトを論理的に含む。コンテナは空のことがある。コンテナはまた、他のコンテナを含むことができる。コンテナマネージャ４１２は、アプリケーション３０２、暗号ＡＰＩ３０４、および／またはスマートカードがこのようなコンテナのアクティビティを実行する際に、それをサポートすることができる。例えば、コンテナを使って、公開鍵／秘密鍵のペアを記憶することができる。これは、しばしば、鍵コンテナと呼ばれる。コンテナマネージャ４１２は、１つまたは複数のＡＰＩを含むことができる。
【００４９】
その他の特定の実施形態では、スマートカード（またはその他の同様のデバイス）がそのロジック、機能、データの記憶、コンテナ、証明書、鍵などを管理できるように、さらなる管理ＡＰＩ４０６が提供される。このような追加およびオプションのＡＰＩを、特に、１つまたは複数のスマートカードをサポートするように構成することができる。
【００５０】
本発明の特定の例示的実施形態によれば、暗号マネージャ４１４は、暗号操作のためのインタフェースサポートを提供するように構成される。一例では、暗号マネージャ４１４を、１つまたは複数の鍵ペア、アルゴリズム、証明書などを利用することができる、スマートカード３０８ａ〜ｎの暗号ロジックによって、データの暗号化、解読、ハッシュ、メッセージのダイジェスト、署名などをサポートするように構成することができる。暗号マネージャ４１４はまた、１つまたは複数のＡＰＩを含むこともできる。
【００５１】
例示的スマートカードインタフェースの構成
このセクションでは、本発明のさらなる特定の実施形態による、さらなる例示的実施形態の詳細を提供する。ここでの目的は、本発明の範囲を限定することではなく、さらに他の実施形態に適合させることが可能な、特定の実施形態に特有の特徴および技術を紹介することである。
【００５２】
このことを念頭に置いて、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム、およびその中に提供されているＣｒｙｐｔｏＡＰＩで使用するための例示的スキームおよび技術を提供する。ここでは、ベースＣＳＰを、ＣｒｙｐｔｏＡＰＩ、および必要に応じて、１つまたは複数のスマートカード特有モジュールで動作するように提供する。さらなる例示的実施形態に従って、オプションのスマートカード管理ＡＰＩについても説明する。特定の実施形態においては、これらのスマートカード管理ＡＰＩの１つまたは複数は、ベースＣＳＰを除いても有益であることを認識されたい。
【００５３】
この構成およびその他の同様の構成の基本的な設計目標は、スマートカードまたはその他の同様の処理／ロジック構成の飛躍的なパフォーマンス、セキュリティ、およびロバスト性を提供することである。この例では、ベースＣＳＰおよび／または管理ＡＰＩが、スマートカード、ＣｒｙｐｔｏＡＰＩ、および呼び出しているアプリケーションの動作可能な結合／インタフェースのニーズを、完全に、またはそのほとんどをサポートする基盤を提供するように設計される。上述のように、ベースＣＳＰおよび管理ＡＰＩは、有利には、ＣｒｙｐｔｏＡＰＩを介してアプリケーションをサポートする必要が生じる可能性がある、様々なタイプのスマートカードおよび／またはその他の同様のデバイスの、全部ではないがほとんどにおいて共通であり、かつ／または共通であると期待される特定の機能に対する、必要なサポートを提供する。
【００５４】
この例では、ＣｒｙｐｔｏＡＰＩは、スマートカード特有の機能から抽出されたものである。したがって、ＣｒｙｐｔｏＡＰＩは、アプリケーション／スマートカード間のインタフェース中に第１のレベルを形成する。例えば、特定のＡＰＩは、様々なスマートカードまたはその他の同様のデバイスの利用法のシナリオを完全にサポートするように、このレベルにおいて提供される。ベースＣＳＰは、この例示的アプリケーション／スマートカード間のインタフェース中に第２のレベルを形成する。特定の実施形態では、スマートカード管理ＡＰＩはまた、この第２のレベルに常駐する。アプリケーション／スマートカード間のインタフェースの第３のレベルは、必要に応じて、１つまたは複数のスマートカード特有モジュールを含む。ここで、スマートカード特有のモジュールは、ベンダ特有の、およびカード特有の実装依存性から抽象化される可能性が高い。このようなスマートカード特有モジュールは、例えば、１つまたは複数のカード特有ＡＰＩによって定義される。
【００５５】
この例では、共通のスマートカード機能には、ＰＩＮで保護される可能性が高い、秘密鍵の記憶（少なくとも１つの秘密鍵について）が含まれる。秘密鍵は、このように、「デフォルト」の鍵コンテナ内に記憶することができる。この例で実施しているように、たった１つの鍵が提供／許可される場合には、それは鍵交換タイプである。スマートカードの機能にはまた、少なくとも１つのスマートカードのログオン証明書の記憶も含まれる。ここで、例えば、証明書は、公開読出し可能で、ＰＩＮによる書込み保護を施すことができる。
【００５６】
この例では、共通のスマートカード機能には、複数の証明書および／または鍵のサポートも含まれる。複数の鍵を記憶することもできる。「デフォルト」の鍵コンテナを与えることが役立つ場合もあるが、各秘密鍵は、関連する鍵コンテナ名を持つことができる。各秘密鍵は、例えば、鍵タイプ（例えば、署名、鍵交換など）など、それに関連付けられた１組のプロパティを備えることができる。その他の例示的な鍵のプロパティには、鍵の寿命、鍵のサイズ、および／または関連する証明書および公開鍵の識別情報が含まれる。
【００５７】
複数の証明書を、可能には異なる使用法で、記憶することができる。特定の実施形態では、秘密鍵ごとに複数の証明書をサポートすることが望ましい場合がある。各証明書は、基本的に、関連付けられた秘密鍵にそれをリンクする、識別情報を有することができる。
【００５８】
共通機能には、スマートカードの公開データ部分中に記憶することができるルート証明書も含めることができる。このルートへのアクセスは、ユーザの公開証明書データにアクセスする場合と同じはずである。ルート証明書は、ＭｉｃｒｏｓｏｆｔルートやＶｉｓａルートなど、ユーザの主要信頼ポイントであってよい。このような機能は、ユーザプロファイル、したがってユーザのルートストアを、ユーザが利用することができない、または修正することができない環境においては役立つ場合がある。その一例が、キオスクにおけるサーバの認証である。
【００５９】
スマートカード上で、汎用証明書ストア機能も共通にすることができる。これは、全般的なカードの記憶が増大するにつれて一層役立つようになる場合がる。ユーザは、例えば、全ルートストアをカード上に保持するように、あるいは一部のＣＡ（認証局）証明書を保持するように決めることができる。
【００６０】
データの再方向付けも、別の潜在的な共通機能である。ここで、例えば、スマートカードの公開データ部分は、ＵＲＬまたは、ユーザの個人データの残りの部分を識別する、同様のものを含むことができる。この機能の興味深い使用法には、ユーザデータの集中型記憶が含まれる。この場合、これには、ユーザの証明書、カード上に記憶された鍵で暗号化された「あまり重要ではない」秘密鍵、アドレス帳データなどを含めることができる。
【００６１】
ＣｒｙｐｔｏＡＰＩの挙動、およびアプリケーション／スマートカード間のインタフェース構成５００が満たすニーズをよりよく理解するためには、スマートカードに関連する使用法のシナリオを考えてみることが役立つ。以下のカード使用法シナリオは、クライアントデバイス上においてそれぞれのスマートカードのユーザ操作が実行されたときからの、ベースＣＳＰの追跡に基づいたものである。
【００６２】
２つの例示的シナリオは、スマートカードのログオン、およびスマートカードユーザの登録を含む。以下の追跡のそれぞれは、所与のシナリオで使用されるＣｒｙｐｔｏＡＰＩの呼出し、および、もしあれば、そのＡＰＩコールの結果生じる、その後のスマートカード操作から成る。
【００６３】
ログオン開始プロセス：
【００６４】
【表１】
【００６５】
−このコンテナはすでに開かれているため、キャッシュデータを使用する。
【００６６】
【表２】
【００６７】
証明書伝搬プロセスの開始：
このコンテナの鍵のタイプはすでにわかっており、それは署名ではない。
ＣｒｙｐｔＤｅｓｔｒｏｙＫｅｙ
ＣｒｙｐｔＤｅｓｔｒｏｙＨａｓｈ
ＣｒｙｐｔＲｅｌｅａｓｅＣｏｎｔｅｘｔ
Ｐｉｎ Ｃｈａｎｇｅ
【００６８】
【表３】
【００６９】
ユーザの登録：
【００７０】
電子署名
【００７１】
【表４】
【００７２】
例示的ＣｒｙｐｔｏＡＰＩ操作
ＣＰＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
特定の実施形態では、ＡｃｑｕｉｒｅＣｏｎｔｅｘｔを呼び出すことによって、そのようなデータをできるだけ早くキャッシュするように、ＣＳＰＱｕｅｒｙＣａｐａｂｉｌｉｔｉｅｓ、ＣＳＰＱｕｅｒｙＦｒｅｅＳｐａｃｅ、およびＣＳＰＱｕｅｒｙＫｅｙＳｉｚｅｓ関数が呼び出される。次の例示的シナリオでは、指定されたコンテナを備えたスマートカードが見つかると、例えば、コンテキストフラグ、コンテナ名、対応するスマートカードのシリアル番号、スマートカードにキャッシュされているデータへのポインタ、スマートカード選択ヒューリスティックス、および／またはコンテナ指定レベルなど、ユーザのコンテキストデータを使って、新しいＨＣＲＹＰＴＰＲＯＶが作成される。
【００７３】
ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔの呼出しに応答して、ベースＣＳＰは、呼出し側が指定したコンテナを、特定のカード／リーダにマッチさせようと試みる。呼出し側は、例えば、以下に記載するように、様々なレベルの特有性でコンテナ名を与えることができ、そのコンテナ名は、より特有な要求からより特有ではない要求の順に、すなわち、リーダ名およびコンテナ名、リーダ名およびデフォルトコンテナ（例えばＮＵＬＬ）、コンテナ名のみ、および／またはデフォルトコンテナ（例えばＮＵＬＬ）のみの順でソートされる。一般に、リーダ名が提供される最初の２つの場合については、ベースＣＳＰは、指定されたリーダをサーチして、そのリーダに挿入されているスマートカード上で、要求された操作を実行する。リーダ名が提供されない次の２つの場合には、ベースＣＳＰは、現在の要求に適したカード／リーダについて、命令されたサーチを実行する。この場合、ベースＣＳＰにすでにわかっているスマートカードから開始して、現在わかっているすべてのスマートカード／リーダへと続く。上記のそれぞれの場合について、ベースＣＳＰを、例えば、キャッシュされているカードデータのリスト中で、マッチするスマートカードをサーチするように構成することができる。したがって、このようなキャッシュは、ベースＣＳＰがそれまでに遭遇したスマートカードのリスト、および関連するカード状態情報を含むことができる。一般に、マッチするスマートカードがキャッシュ中に見つかった場合には、そのキャッシュ項目に関連するスマートカードハンドルをテストすることができる。これは、スマートカードが依然としてリーダ中にあるかどうかを判断するための１つの方法である。
【００７４】
コンテナ操作
この例示的実施形態では、コンテナ操作を、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔによって要求することができる。例えば、コンテナ操作は、新しいコンテナの作成（ＣＲＹＰＴ＿ＮＥＷＫＥＹＳＥＴ）、既存のコンテナを開くこと、および／またはコンテナの削除（ＣＲＹＰＴ＿ＤＥＬＥＴＥＫＥＹＳＥＴ）を含むことができる。ユーザコンテキストを特定のスマートカードおよびリーダに関連付けるために使用されるヒューリスティックスは、要求されたコンテナ操作、および使用されたコンテナ指定のタイプまたはレベルに基づくことができる。
【００７５】
ここで、コンテナ作成操作を、例えば以下のように制限することができる。
【００７６】
サイレントコンテキストなし−鍵コンテナの作成では、常に、例えばＰＩＮプロンプトなどのユーザインタフェース（ＵＩ）を示すことができなければならない。
【００７７】
既存のコンテナを上書きしない−指定したコンテナが選択したスマートカード上にすでに存在する場合は、別のスマートカードを選択するか、その操作を失敗する（これは、カード指定のタイプまたはレベルによることが可能）。
【００７８】
以下の例示的コンテキストフラグを利用することができる。
ＣＲＹＰＴ＿ＳＩＬＥＮＴ−この場合、例えば、この操作の間、ＵＩは何も表示されない。
ＣＲＹＰＴ＿ＭＡＣＨＩＮＥ＿ＫＥＹＳＥＴ−例えば、この操作の間、キャッシュされているデータは何も使用されない。
ＣＲＹＰＴ＿ＶＥＲＩＦＹＣＯＮＴＥＸＴ−例えば、カード上の公開データにのみアクセスすることができる。
【００７９】
「コンテナ操作」および「コンテナの指定」に加えて、上記のＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔフラグなど、カード選択の間のその他のユーザオプションについても考慮しなければならない。
【００８０】
カード選択の挙動
特定の例示的シナリオでは、ユーザは、スマートカードを挿入するように促される。ユーザコンテキストがサイレントの場合には、この操作は失敗し、ＵＩは何も表示されない。そうでない場合には、ユーザは、ＵＩに応答して、スマートカードを挿入するか、またはおそらく「キャンセル」をクリックすることができる。ユーザがキャンセルすると、操作は失敗する。
【００８１】
特定のコンテナ指定を使うと、指定したリーダ中のスマートカードのみをマッチの対象とみなすことができるので、スマートカード選択プロセスの複雑さを低減することができる。したがって、例えば、ベースＣＳＰは要求されたリーダを見つける。それが見つからない場合には、プロセスは失敗する。リーダ中にスマートカードがなかった場合には、例えばＵＩを介して、スマートカードを挿入するようユーザを促すように、ベースＣＳＰを構成することができる。
【００８２】
リーダ中にスマートカードが挿入され、動作可能に接続されると、ベースＣＳＰは、選択されたスマートカード上のデフォルトコンテナの名前の判断を支援する。例示的なコンテナ操作には、例えば、既存のコンテナを開くこと、コンテナの削除、および／または指定されたコンテナを見つけることが含まれる。指定されたコンテナがスマートカード上に見つけられなかった場合には、再び、カードを挿入するように、特定の方法でユーザを促すことができる。新しいコンテナを作成するときに、指定されたコンテナがスマートカード上にすでに存在していた場合には、プロセスは失敗する。
【００８３】
本発明のさらなる特定の態様によれば、該当するスマートカードをユーザコンテキストにマッチさせるように、ベースＣＳＰを構成することができる。与えられた基準を満たす、キャッシュされているスマートカードは複数存在する可能性があるため、これは有益である。
【００８４】
特定の実施形態では、ベースＣＳＰにわかっている各スマートカードは、特定の方法で記憶されている（例えば、プロセス全体にわたって、すでにアクセスされたカードのリストをキャッシュすることができる）。既存のコンテナを開くために、ベースＣＳＰは、識別された（例えば指定された）コンテナ名を、スマートカードのコンテナ名のキャッシュ中で探す。コンテナ名は、デフォルトコンテナを指定する、ＧＵＩＤまたはＮＵＬＬの場合がある。キャッシュされているＳＣＡＲＤＨＡＮＤＬＥに対して、そのフレッシュネスを確認するための操作が試みられる。
【００８５】
キャッシュされているカードが取り外され、コンテキストがサイレントであると判断された場合には、ベースＣＳＰは、別のマッチするスマートカードをサーチし続けることができる。キャッシュされているスマートカードが取り外され、コンテキストが非サイレントである場合には、ユーザにスマートカードの挿入を促すＵＩを表示することができる。ユーザがＵＩ内の「キャンセル」をクリックすると、ベースＣＳＰはマッチするカードをサーチし続けることができる。ベースＣＳＰのキャッシュ中にマッチするカードが見つからない場合には、例えば、適切な（ａｐｐｒｏｐｒｉａｔｅ）コールバックフィルタを用いてＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄ（）呼出しを使うことにより、要求されたコンテナを備えた、マッチするカードを見つけることができる。ＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄに提供されたコールバックは、列挙された各カードについて、ベースＣＳＰキャッシュのエントリを作成する。
【００８６】
コールバックは、遭遇したスマートカードのそれぞれについて、新しいスマートカードキャッシュエントリを作成し、それを、ベースＣＳＰのグローバルリストまたはその他の同様のデータ構造中に入れる。カードキャッシュ構造では、提供されたＳＣＡＲＤＨＡＮＤＬＥおよび新しいＰＩＮキャッシュハンドルを保持するために、新しいカード特有データ構造を作成することができる。
【００８７】
この例示的構成においては、ユーザにＰＩＮを催促する場合には、コンテナ作成においてＣＲＹＰＴ＿ＳＩＬＥＮＴが許可されない。この場合、カード選択のＵＩが必要なことがある。その他の操作については、呼出し機能は、デフォルトコンテナに対して「確認」コンテキストを得、次いで、ＣｒｙｐｔＳｅｔＰｒｏｖＰａｒａｍを呼び出して、その後の操作のためにユーザＰＩＮをキャッシュすることができる。しかし、コンテナ作成の場合には、このような操作を実行する対象となるコンテナがまだない場合がある。
【００８８】
ベースＣＳＰにすでにわかっている各カードについて、記憶されているＳＣＡＲＤＨＡＮＤＬＥをリフレッシュすることができる。以下のチェックを行うこともできる。すなわち、スマートカードが除去されている場合にはサーチを続ける。また、スマートカードが依然として存在するが、すでに指定されたコンテナを備えている場合には、サーチを続ける。また、スマートカードが利用可能であるが、ＣＳＰＱｕｅｒｙＣａｒｄＦｒｅｅＳｐａｃｅの呼出しによって、カードにさらなる鍵コンテナのための十分な記憶がないことが示された場合には、サーチを続ける。そして、それ以外の場合には、上記の基準を満たす最初の利用可能なスマートカードを、コンテナ作成のために使用することができる。
【００８９】
マッチするスマートカードがベースＣＳＰキャッシュ中に見つからない場合には、列挙されたカードをフィルタにかけるために使用するコールバックを利用して、候補スマートカードがまだ指定されたコンテナを備えていず、また、ＣＳＰＱｕｅｒｙＦｒｅｅＳｐａｃｅが、そのカードが追加コンテナ用の十分なスペースを有することを示していることを確認することができる。適切なカードが何も見つからない場合には、スマートカードを挿入するようユーザを促すＵＩを表示することができる。
【００９０】
コンテナの削除を試みるときに、指定されたコンテナ名がＮＵＬＬである場合には、プロセスは失敗する。これは、特定のリーダが指定されていない、曖昧な場合であるとみなすことができる。
【００９１】
すでにベースＣＳＰにわかっているスマートカードのそれぞれについて、記憶されているＳＣＡＲＤＨＡＮＤＬＥをリフレッシュして、以下のチェックを行うことができる。すなわち、スマートカードが指定されたコンテナを備えていない場合には、サーチを続ける。また、コンテキストがサイレントであり、スマートカードが指定されたコンテナを備えているが、取り外されている場合には、サーチは失敗する。また、コンテキストが非サイレントであり、スマートカードが指定されたコンテナを有しているが、取り外されている場合には、スマートカードを挿入するようユーザに促すＵＩを表示することができる。また、マッチするスマートカードがベースＣＳＰのキャッシュ中に見つからない場合には、列挙カードをフィルタにかけるために使用されるコールバックを使って、候補カードが指定されたコンテナを備えていることを確認する。また、コンテキストが非サイレントであり、適切なスマートカードが見つからない場合には、スマートカードを挿入するようユーザに促すＵＩを表示することができる。そして、その他の場合には、プロセスは失敗する。
【００９２】
本発明の特定の実施形態によれば、以下のＡＰＩが定義される。
【００９３】
【表５】
【００９４】
ＰＣＳＰ＿ＰＲＯＶ＿ＣＴＸとして初期化する。
ｐｓｚＣｏｎｔａｉｎｅｒ
【００９５】
呼出し機能は、例えば、完全修飾されたコンテナロケーションまたは単純なコンテナ名のいずれかを指定することができる。前者は、リーダ名とコンテナ名の両方を含むことができる。ベースＣＳＰは、完全修飾されたコンテナがあるかどうかに応じて、異なるセマンティックスを使用して適切なカードの位置を突き止めるように構成することができる。
【００９６】
【表６】
【００９７】
呼出し側の要求が有効であることを確認する。
【００９８】
鍵タイプ−サポートされる鍵タイプは、ＡＴ＿ＳＩＧＮＡＴＵＲＥおよびＡＴ＿ＫＥＹＥＸＣＨＡＮＧＥである。
【００９９】
鍵サイズ−ＣＳＰＥｎｕｍＫｅｙＳｉｚｅｓ（）を呼び出して、指定された鍵サイズが有効であることを確認する。鍵サイズが指定されていない場合には、その機能によって返されたデフォルト鍵サイズを使用することができる。
【０１００】
鍵コンテナ−ユーザコンテキスト中に指定されているコンテナがすでに存在し、要求されたタイプの鍵を備えており、また、コンテキストがサイレントである場合には、プロセスは失敗する。そうでない場合には、その鍵の置換えをユーザに確認するためのＵＩが表示される。次いで、ＣＳＰＣｒｅａｔｅＣｏｎｔａｉｎｅｒ（）を呼び出して、例えば、鍵作成フラグ、コンテナ名、鍵サイズなどを指定することができる。
【０１０１】
【表７】
【０１０２】
【表８】
【０１０３】
スマートカードインタフェース層
本発明の特定の態様によれば、ＰＣＳＣと暗号法の関連はこのレベルまで抽象化され、この場合、カードデータのキャッシングおよび論理カードファイルシステムのフォーマットを処理することができる。
【０１０４】
スマートカードインタフェース操作
スマートカードインタフェース操作を行う目的の１つは、カード特有操作と、直接、ベースＣＳＰが行う機能呼出しの間の密結合を確立することである。特定の場合においては、カードインタフェース操作は、カード特有操作からできるだけ多くの一般コードを取り除き、カードデータのキャッシュ層としての役割を果たすことである。一般に、スマートカードから読み出すことができるデータはどれも、ベースＣＳＰプロセス中に記憶することができる。その後、そのデータに対する要求があると、キャッシュされたコピーのフレッシュネスがチェックされ、次いで、適切な場合にはそれが使用される。スマートカードインタフェース操作は、キャッシュされたデータが利用可能でない場合にのみ、カード特有操作を呼び出す。これは、スマートカードとの通信はきわめて遅くなりがちなため、有利である。一方、キャッシュされているデータはどれも、使用する前にその妥当性を確認することが重要である。確認しない場合、スマートカードに基づいた認証のセキュリティが危うくなる可能性がある。キャッシュのフレッシュネスチェックがこの問題を解決する。
【０１０５】
証明書の列挙
特定の実施形態では、「証明書読出し」操作において、コンテナの識別を指定し、対応する証明書の位置を突き止めるように、ベースＣＳＰを構成することができる。この場合、証明書の列挙はなく、コンテナの列挙があるだけである。もちろん、すべてのコンテナが証明書を持っているわけではない。２つまたはそれ以上の証明書の間で鍵を共用することが望ましい場合もある。そのために、コンテナの列挙に加えて、証明書の列挙をサポートする必要がある場合がある。
【０１０６】
証明書の列挙は、ファイルフィルタ中で「ＵｓｅｒＣｅｒｔ」というプレフィックスを指定することにより、ＣＳＰＥｎｕｍＦｉｌｅｓを呼び出すことによって行うことができる。証明書については、デフォルト鍵コンテナに属するものが何かあれば、証明書のファイル名ＧＵＩＤがコンテナのＧＵＩＤ名と同じ場合がある。一般に、証明書については、１つの鍵について複数の証明書をサポートするように、対応する鍵コンテナの名前を、記憶されている証明書データ中に含めることができる。しかし、証明書とその鍵コンテナが、必ずしも同じＧＵＩＤ名を共用する必要はない。
【０１０７】
例示的スマートカード機能
【０１０８】
【表９】
【０１０９】
鍵コンテナ
鍵コンテナ名を、論理カードファイル名として指定することができる。すなわち、リーダ名とコンテナ名の両方を指定する、完全修飾されたコンテナ名は、カードインタフェースの機能には渡されないはずである。適用可能なＡＰＩのそれぞれを、スマートカードのコンテキスト情報を受け取るように構成することができるため、完全修飾された名前のコンテナ名部分を渡すことはできる。
【０１１０】
【表１０】
【０１１１】
【表１１】
【０１１２】
例示的暗号操作
特定の実施形態によれば、データパディングを利用することができる。ＲｓａＥｎｃｒｙｐｔのような関数を使って、データパディングを処理してスマートカードにディスパッチするか、または、要求された公開鍵をスマートカードから抽出することができる。スマートカードが公開鍵のエクスポートをサポートしている場合には、例えば、ＲＳＡ暗号化操作、カーブに基づいた暗号化操作、および／または同様のものをサポートするように、ベースＣＳＰを構成することができる。特定の例示的実施形態によれば、ベースＣＳＰは、公開鍵のエクスポートをサポートしないカードを「サポート」しない。この場合、公開鍵は、それらのそれぞれのコンテナデータとともにキャッシュすることができる。
【０１１３】
【表１２】
【０１１４】
カードインタフェースのキャッシング
特定の実施形態では、スマートカードがリムーバブルなので、「ライトスルー」キャッシュスキームが利用されている。このスキームでは、最後の書込み者が勝ち取る。ベースＣＳＰは、データの矛盾のために書込み操作を失敗するように要求されることはない。例えば、プロセスＢが最後にＸを読み出してから、プロセスＡが項目Ｘをスマートカードに書き込んでいる場合がある。プロセスＢは、その後、Ｘを書き込む可能性があり、その場合、これは、プロセスＡ中にキャッシュされているＸを、矛盾しているとみなす。この状況を緩和するために、キャッシュには、リーダが一貫したデータを得られるようにするための助けとなる、タイムアウト（機能停止）を設けるべきである。様々なタイプのデータに対して異なるタイムアウトを使用することが可能である。
【０１１５】
キャッシュの実装は、例えば、よく知られたカード上のロケーションに記憶されている、１組のカウンタに基づくことが可能である。このカウンタは、書込み操作を行っているベースＣＳＰが、インクリメントすることができる。カウンタの値は、キャッシュデータによって正しく反映されている、カード状態への最後の修正を識別する。簡単にするために、限定された細分性で、修正を追跡することができる。例として、以下のカードエリアを、それぞれを全体として、キャッシュによって追跡することができる。［コンテナ｜データファイル｜ＰＩＮ］。
【０１１６】
別の例では、プロセスがスマートカードのデータファイルのいずれかを修正した場合に、カード上の「データファイル」のキャッシュロケーションを、現在のタイムスタンプで更新することができる。いずれかのデータファイルに対する、いずれかの他のプロセスからの、いずれかのその後の読出し操作は、キャッシュミスになる。これは、要求されたファイルがすでに正しくキャッシュされている場合でも、最後の操作の後で別のカード上のファイルが修正されたならば、その要求されたファイルをカードから直接、読み出さなければならないことを意味する。
【０１１７】
よく知られたカード上のキャッシュのロケーションは、予め決定された名前を有する特定のデータファイルのことがある。したがって、例えば、キャッシュの状態の更新を、このよく知られたファイル名を使って、ＣａｒｄＲｅａｄＦｉｌｅおよびＣａｒｄＷｒｉｔｅＦｉｌｅ操作によって行うことができる。キャッシュの状態を正しく保持するために必要とされるカードとの対話量を低減するために、キャッシュデータを、それ以外のいずれかのデータなしに、それ自身の論理ファイル中に記憶することができる。これによって、ベースＣＳＰは、カードから最低必要量のデータの読出しおよび書込みを行って、キャッシュの状態を保持することができる。
【０１１８】
本発明の特定の実施形態によれば、カードのキャッシュファイルの内容は、予め定義された構造である。スマートカードを取り外した場合、例えば、そのスマートカードがシリアル番号を使って初期化されている場合には、スマートカードのキャッシュが、ベースＣＳＰをロードしたプロセス中に安全に残っていることが可能である。スマートカードを再挿入した場合、スマートカードのシリアル番号がマッチし、キャッシュファイルが変更を示さないならば、すでにキャッシュされているデータはフレッシュであるとみなすことができる。
【０１１９】
初期化
ログオンなど、重要な操作の間の応答時間を改善するための最適化として、特定のデータをスマートカードから予め読み出し、キャッシュしておくことができる。例えば、このようなキャッシングは、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔを呼び出す間に発生し得る。予め読み出すためのスマートカードデータの例としては、いずれかのよく知られたカードデータファイルの内容が挙げられる。これには、カードのシリアル番号およびデフォルトのコンテナ名が含まれる場合がある。したがって、証明書はスマートカード上に記憶されている１つまたはそれ以上のデータ項目であることが多いので、例えば、この時点で、カードからユーザの証明書のいずれかを読み出すと有利である。実際、特定の実施形態では、そうすることによって、ログオンを相当スピードアップさせることができる。ユーザログオンまたは認証プロセス（例えば、Ｗｉｎｌｏｇｏｎ）などのカードクライアントは、このメカニズムを賢明に使って、例えば、ユーザがＰＩＮを入力している間にユーザのスマートカードデータをプレロードする。
【０１２０】
データの書込み
キャッシュの更新は、トランザクションに基づくことが可能であり、キャッシュの更新を必要としている、すぐ前の操作と同じトランザクション内で行うことができる。現在、スマートカードの実装は、一般に、ロールバックできないミューテックスであるため、スマートカードのトランザクションは、技術的には誤称である。しかし、ミューテックスが解除される前に、キャッシュ状態の更新およびカードデータの更新の両方がその順番で行われる。この例を以下に示す。そこでは、ベースＣＳＰがＦｏｏと呼ばれる一般的なデータファイルをカードに書き込んでいる。
【０１２１】
【表１３】
【０１２２】
データの読出し
ベースＣＳＰからのスマートカードへの読出し要求のそれぞれにおいてＣａｃｈｅＦｉｌｅをカードから読み出すことができる。当該のデータエリアが修正されていない場合（例えば、汚れていない場合）には、可能であれば、キャッシュデータが読出し要求を満たすことがある。当該のデータエリアが汚れている場合、または要求されたデータがキャッシュされていない場合には、カードの読出しが実際に行われて、その結果がキャッシュされる。
【０１２３】
例として、特定の実施形態では、スマートカード中の機能を、呼び出されたときに以下の動作を行うように構成することができる。これらの動作は、キャッシュの保全性を保証するという目的にかない、結果的にスマートカードへの呼出回数を低減する。
ａ）ベースＣＳＰが、当該のスマートカードについて作成した、キャッシュされた項目をルックアップする
ｂ）そのような項目が存在しない場合には、ｆＩｓＣａｃｈｅｄ＝Ｆａｌｓｅである。
ｃ）そうでない場合には、ｆＩｓＣａｃｈｅｄ＝Ｔｒｕｅである。項目のキャッシュスタンプを得る。それをｍｙＣａｃｈｅＳｔａｍｐと呼ぶ。
ｄ）このＳＣＡＲＤＨＡＮＤＬＥ上でトランザクションを開始する。
ｅ）ＣａｒｄＲｅａｄＦｉｌｅ（）を使って、キャッシュファイルを読み出す。
ｆ）キャッシュファイル中のどの値が所望のカードデータ項目（コンテナ、一般データ、またはＰＩＮ）に対応するかを判断する。これをｃｕｒｒｅｎｔＣａｃｈｅＳｔａｍｐと呼ぶ。
ｇ）ｆＩｓＣａｃｈｅｄがＦａｌｓｅ、またはｃｕｒｒｅｎｅｔＣａｃｈｅＳｔａｍｐ＞ｍｙＣａｃｈｅＳｔａｍｐである場合には、適切なカード特有モジュール（例えばＡＰＩ）によって、要求されたデータ項目をスマートカードから読み出す。
ｈ）そうでない場合には、キャッシュデータを使用する。
ｉ）このＳＣＡＲＤＨＡＮＤＬＥ上でのトランザクションを終了する。
ｊ）スマートカードから項目を読み出さなければならない場合には、新しいデータでキャッシュを更新し、ｃｕｒｒｅｎｔＣａｃｈｅＳｔａｍｐをその新しいデータに関連付ける。
ｋ）要求されたデータを呼出し側に返す。
【０１２４】
スマートカードのキャッシングシナリオ
セッションを通じて、ほぼ最低限のデータ量だけをスマートカードから読み出すことが賢明である場合がある。これは、変更されていないデータをスマートカードから２度読み出すべきではないことを意味する。そうではなく、変更されていないデータは、常に、ベースＣＳＰのカードデータのキャッシュから検索されるべきである。この場合、例えば、セッションを、ベースＣＳＰをロードして、所与のスマートカード上で操作を実行するプロセスの存在期間であるとみなすことができる。
【０１２５】
セッションを通じて、スマートカードのキャッシュはほぼ一貫している。すなわち、例示的ベースＣＳＰを使用した場合、正しくない、期限切れのデータをキャッシュから読み出すことはできない。その他のプロセスが同じスマートカードにアクセスしている場合にさえ、それが言える。
【０１２６】
シナリオ＃１−ユーザログオンのための初期ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
入力：
Ｎａｍｅｄ Ｒｅａｄｅｒ
Ｄｅｆａｕｌｔ Ｃｏｎｔａｉｎｅｒ
【０１２７】
キャッシュされているスマートカードのリストをサーチする。何も見つからない。
【０１２８】
ＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄ（）によって、スマートカードを列挙する。このＡＰＩに渡されるコールバックが、リーダ名をフィルタにかける。
【０１２９】
このカードのためのＣＡＲＤ＿ＤＡＴＡ構造が作成されて、ベースＣＳＰにわかっているカードのリストに追加される。これは、ＣＳＰのカードリストキャッシュ中の最初の項目である。
【０１３０】
このカードのシリアル番号について、ＣＳＰＲＥＡＤＦＩＬＥ（）を呼び出す。まだシリアル番号がキャッシュされていないので、この結果、ＣａｒｄＲｅａｄＦｉｌｅ（）が呼び出される。
【０１３１】
このカードのデフォルトコンテナの名前について、ＣＳＰＲｅａｄＦｉｌｅ（）を呼び出す。まだコンテナ情報がキャッシュされていないので、この結果、ＣａｒｄＲｅａｄＦｉｌｅ（）が呼び出される。
【０１３２】
このコンテナについて、ＣＳＰＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）を呼び出す。現在キャッシュされているコンテナ情報がそのコンテナの名前であるため、この結果、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）が呼び出される。
【０１３３】
シナリオ＃２−ユーザログオンのための第２のＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
入力：
Ｎａｍｅｄ Ｒｅａｄｅｒ
Ｎａｍｅｄ Ｃｏｎｔａｉｎｅｒ
【０１３４】
指定されたコンテナを探して、キャッシュされているカードのリストをサーチする。それがキャッシュ中に見つかる。キャッシュされているＳＣＡＲＤＨＡＮＤＬＥをテストして、それが依然として有効であることを確認する。
【０１３５】
そのシリアル番号について、ＣＳＰＲｅａｄＦｉｌｅ（）を呼び出す。キャッシュされている値が見つかる。キャッシュ読出しプロセスは、この項目のキャッシュスタンプに基づいて、そのキャッシュされているデータが最新であることを確認する。特定の実施形態では、サニティチェックとして、カードからのこの値を再度読み出すことができる。これは、ＧＵＩＤコンテナ名がすでにマッチしている場合には必要ない。
【０１３６】
指定されたコンテナ名について、ＣＳＰＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏｒ（）を呼び出す。キャッシュされているデータが見つかる。キャッシュ読出しプロセスは、そのキャッシュデータが最新のものであることを確認する。
【０１３７】
ファイルフォーマット
完全修飾された論理ファイル名、例えば、ベースＣＳＰとスマートカード特有モジュールの間に基礎を置くタイプは、論理ディレクトリ名、およびその後に続く論理ファイル名から成る。したがって、この例では、「ＤｉｒＮａｍｅ／ＦｉｌｅＮａｍｅ」というパターンになる。ここで、スマートカード特有モジュールは、論理ファイル名を物理カードロケーションにマップする必要がある。
【０１３８】
例示的論理ディレクトリ名
次の論理ディレクトリ名、すなわち、ＲｏｏｔＣｅｒｔ、ＵｓｅｒＣｅｒｔ、およびＧｅｎｅｒａｌＤａｔａは、予め定義することができる。
【０１３９】
例示的論理ファイル名
うまく形成された論理ファイル名は、以下の規則に従っている場合がある。
【０１４０】
ユーザ証明書については、論理ファイル名を、ＧＵＩＤ、および情報を識別する２、３バイトをそれに加えたもので構成する。これは、最大約３７＋３＝４０バイトになる。
【０１４１】
ルート証明書については、論理ファイル名を、公開鍵のハッシュで構成する。これは、ユーザの信頼情報に対する高速クエリを可能にする。
【０１４２】
一般的なカード上のデータについては、論理ファイル名をシリアル番号で構成する。ユーザのデフォルトコンテナ名を表すマスタファイルなど、共通の一般的なデータファイルは、前もって定義されたシリアル番号を有する。
【０１４３】
例示的証明書
一例では、証明書を、以下のデータ構造の形でスマートカード上に記憶することができる。
【０１４４】
【表１４】
【０１４５】
キャッシュファイルのよく知られた名前は、以下のようになるはずである。
”ＧｅｎｅｒａｌＤａｔａ＼ＣａｃｈｅＦｉｌｅ”
＃ｄｅｆｉｎｅ ＣＡＲＤ＿ＣＡＣＨＥ＿ＦＩＬＥ ”ＧｅｎｅｒａｌＤａｔａ＼ＣａｃｈｅＦｉｌｅ”
【０１４６】
キャッシュファイルの内容は、以下の構造のみで構成される。
【０１４７】
【表１５】
【０１４８】
キャッシュファイルの例示的デフォルトアクセス制御リスト（ＡＣＬ）は以下の通りである。
Ｅｖｅｒｙｏｎｅ Ｒｅａｄ， Ｗｒｉｔｅ
Ｓｅｒｉａｌ Ｎｕｍｂｅｒ Ｆｉｌｅ
【０１４９】
シリアル番号ファイルは、カードのシリアル番号を含む。よく知られた名前は以下のようになるはずである。
【０１５０】
シリアル番号ファイルの内容は、以下の構造のみで構成される。
【０１５１】
シリアル番号ファイルのデフォルトＡＣＬは以下の通りである。
【０１５２】
デフォルトコンテナファイルは、スマートカードのデフォルトコンテナのＧＵＩＤを含む。よく知られた名前は以下のようになり得る。
【０１５３】
デフォルトコンテナファイルの内容は、以下の構造を含む。
【０１５４】
ｐｓｚＤｅｆａｕｌｔＣｏｎｔａｉｎｅｒ中に指定されているＧＵＩＤは、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）、ＣａｒｄＰｒｉｖａｔｅＫｅｙＤｅｃｒｙｐｔ（）などの呼出しにおいて直接、使用することができるような方法でフォーマットすることができる。記憶されているＧＵＩＤは、もしあれば、デフォルト鍵コンテナに対応する、デフォルトユーザ証明書の名前も意味する。指定された証明書ファイルにアクセスするには、例えば、ＣａｒｄＲｅａｄＦｉｌｅを呼び出して、返されたＧＵＩＤの前に「ＵｓｅｒＣｅｒｔ＼」を付加して構成したファイル名を指定する。
【０１５５】
デフォルトコンテナファイルのデフォルトＡＣＬは以下の通りである。
【０１５６】
カードストレージエリアは、適切なデフォルトＡＣＬで構成すべきである。
【０１５７】
【表１６】
【０１５８】
【表１７】
【０１５９】
例示的なスマートカード取り外し技術
ここで、スマートカードインタフェースは、例えば、スマートカード特有モジュールからのスマートカードの取り外しの通知にロバストに応答することができるはずである。スマートカード特有モジュールが、スマートカードが取り外されたことを検出した場合には、適切なステータスが返されるはずである。これに応答して、スマートカードインタフェースは、スマートカードに再接続を試みることができる。再接続が成功した場合には、スマートカード特有操作を再度試みるはずである。再接続が失敗すると、そのステータス通知をベースＣＳＰから伝搬することができる。
【０１６０】
ＳＣＡＲＤＨＡＮＤＬＥは、スマートカードインタフェースからスマートカード特有操作に渡されるデータ中に含めることができる。そのハンドルを呼び出した結果、ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤがスマートカードインタフェースに返される。この事例が処理され得る呼出しのリストには、すべてのスマートカード特有操作に、トランザクション開始操作を加えたものが含まれる。
【０１６１】
ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤに応答して、カードインタフェースは、上記によって、復元、再接続、および再試行を試みることができる。これは、スマートカードが再挿入されているかどうかをチェックするためのものである。ベースＣＳＰによるスマートカードの最初期化が失敗し、現在のユーザコンテキストがサイレントではない場合には、ベースＣＳＰは、スマートカードを再挿入するようにユーザを促すＵＩを表示することができる。現在のユーザコンテキストがサイレントである場合、または、ユーザがＵＩ操作において「キャンセル」した場合には、現在のＣｒｙｐｔｏＡＰＩ機能は、ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤで失敗する。
【０１６２】
例示的ベースＣＳＰユーザインタフェース
上述のように、特定の状況においては、ユーザと対話するためにベースＣＳＰが必要とされる場合がある。特定の例示的実施形態では、ベースＣＳＰによって提供されるＵＩは以下のように動作する。
【０１６３】
ベースＣＳＰは、現在のユーザコンテキストがサイレントとして取得されなかった場合、ＵＩを表示することができる。
【０１６４】
ベースＣＳＰによって表示される全てのダイアログは、キャンセルボタンを含む。ユーザが「キャンセル」を押すと、その影響を受けたＣｒｙｐｔｏＡＰＩによって、該当するエラーコードが返される。
【０１６５】
全てのダイアログは、ユーザが入力を行う、どのスマートカード、どの操作などに関して、可能な限り具体的である。
【０１６６】
例示的シナリオ
ユーザコンテキストがサイレントではない場合、ベースＣＳＰは、次のような状況においてＵＩを表示することができる。
【０１６７】
スマートカードの初期化が失敗した場合には、要求されたスマートカードを挿入するようユーザを促す。
【０１６８】
現在挿入されている以外のスマートカードに関連するユーザコンテキストについて、ＣｒｙｐｔｏＡＰＩ操作が要求された場合には、要求されたスマートカードを挿入するようユーザを促す。
【０１６９】
カード特有操作がＰＩＮキャッシュの要求を行った場合には、現在の操作に対してキャッシュされているＰＩＮが正しくない可能性がある。ＳＣＡＲＤ＿Ｗ＿ＷＲＯＮＧ＿ＣＨＶというステータスを、カードインタフェースに返すことができる。応答して、ユーザは、正しいＰＩＮを入力するように促されることがある。その場合、ＰＩＮのキャッシュは更新され、次いで、カード特有操作が再度、試みられる。
【０１７０】
例示的実施形態
可能であれば、スマートカードにはフレンドリな名前を与えるべきである。これは、ＵＩメッセージテキスト中に含めることができる。このフレンドリな名前は、カードの個別化の間に送達することができ、また「ドメインユーザログオンカード」など、比較的一般的なものであってよい。あるいは、スマートカードのシリアル番号を表示することができる。ただし、ユーザが所与のシリアル番号を実際のスマートカードに関連付けることは難しい場合もある。
【０１７１】
合衆国では、ベースＣＳＰパッケージの暗号署名は、ある種の輸出規制を受けるため、ベースＣＳＰのリソースストリングを、ベースＣＳＰ自体とは別のパッケージで配布することができる。
【０１７２】
この例示的ベースＣＳＰでは、以下の２つの別個のダイアログボックスを使用することができる。
カード挿入ダイアログ−このダイアログは、タイトルバー、テキストボックス、およびキャンセルボタンを含むことができる。
ＰＩＮダイアログ−このダイアログは、タイトルバー、テキストボックス、編集ボックス、ＯＫボタン、およびキャンセルボタンを含むことができる。
【０１７３】
スマートカード特有モジュール
この例示的実施形態におけるスマートカード特有モジュールは、標準化された１組のマクロレベル操作を実行して、論理カードファイルシステムオブジェクトを物理カードロケーションにマップするように設計されている。ここで、例えば、各スマートカード特有操作は、単一のアトミックトランザクションを実施する。
【０１７４】
例示的カード特有操作
カード機能
特定の実施形態では、ベースＣＳＰが、特定のスマートカードおよび／またはスマートカード特有モジュールの複数の変形形態をサポートすることが必要な場合がある。所与のスマートカードの機能を利用するために、スマートカード特有モジュールは、スマートカードが提供する１組の機能全てに問い合わせを行うためにベースＣＳＰが使用することができる、ＡＰＩを含むことができる。スマートカードの機能の例には、圧縮アルゴリズムおよびチェックサムによるファイルの保全性の保証が含まれる。圧縮など、ベースＣＳＰが必要とするいずれかの機能がスマートカードによって提供される場合、ベースＣＳＰは、スマートカードによる実行を利用することができる。そうでない場合には、ベースＣＳＰは、この機能を自分自身で実行することができる。
【０１７５】
【表１８】
【０１７６】
入力：
バージョン番号をｐＣａｒｄＣａｐａｂｉｌｉｔｉｅｓ中に設定する。
出力：
Ｓｔａｔｕｓ
Ｆｉｌｌｅｄ−ｉｎ ｐＣａｒｄＣａｐａｂｉｌｉｔｉｅｓ ｓｔｒｕｃｔ
目的：
例えば、圧縮およびファイルのチェックサムなど、このレベルで提供される機能について、スマートカードとスマートカード特有モジュールの組合せに問い合わせる。
【０１７７】
【表１９】
【０１７８】
この例では、コンテナごとに２つの鍵ペアがサポートされる。各鍵には、鍵の使用法、署名、または鍵交換が関連付けられている。その他の特定の実施形態では、単一の鍵ペアまたは２組より多い鍵ペアをサポートすることができる。
【０１７９】
特定の実施形態では、各鍵コンテナに、スマートカード上の対応する証明書に関する識別情報（例えば、証明書データをどこで見つけたらよいかに関する論理情報）を関連付けることもできる。全てのコンテナが対応する証明書を備えるわけではない。これは、鍵ごとに複数の証明書がサポートされるわけではないことを前提にしている。
【０１８０】
入力：
Ｆｉｒｓｔ｜Ｎｅｘｔ
出力：
Ｓｔａｔｕｓ
現在の鍵コンテナのＧＵＩＤ名
目的：
連続する呼出しにおいて、スマートカード上に存在する全ての鍵コンテナの名前をリストする。列挙の最後まで到達しても、出力バッファの内容が変わっていない場合には、ステータスは失敗を表すはずである。
【０１８１】
入力：
ＧＵＩＤ
出力：
Ｓｔａｔｕｓ
目的：
ＧＵＩＤによって指定された鍵コンテナを削除する。コンテナが存在していて、無事に削除された場合には、ステータスは成功を表すはずである。そうでない場合には、ステータスは、コンテナが存在しなかったこと、または特定の理由で削除が失敗したことなどを表すはずである。
【０１８２】
入力：
ＫｅｙＧｅｎ｜ＫｅｙＩｍｐｏｒｔ
ＧＵＩＤ
ＫｅｙＧｅｎの場合には、鍵のタイプおよびサイズも供給されなければならない。
ＫｅｙＩｍｐｏｒｔの場合には、鍵データも供給されなければならない。
出力：
Ｓｔａｔｕｓ
目的：
ＧＵＩＤという名前の新しい鍵コンテナを作成する。この新しいコンテナは、呼出しが成功した場合には、常に有効な鍵を含む。新しいコンテナを作成する２通りの方法は、ランダムな鍵の生成による方法、および既存の鍵データのインポートによる方法である。
【０１８３】
デフォルトコンテナがすでに署名鍵を有するときに、アプリケーションが、デフォルトコンテナを使用し、鍵交換の鍵を利用して証明書を作成することを試みた場合、このプロセスは、コンテナがすでに「一杯」であり、現在の鍵が正しく使用されていないために、１鍵モデルにおいては失敗する。正しい挙動は、そのプロセスを新しい／異なるコンテナに再方向付けすることである場合がある。
【０１８４】
入力：
ＧＵＩＤ
出力：
Ｓｔａｔｕｓ
Ｄａｔａ
目的：
指定された鍵コンテナに、その鍵のタイプ（例えば、署名または鍵交換）など、それが含む鍵に関する追加情報を問い合わせる。その挙動は、全ての入手可能なコンテナ情報を返すことであることが可能である。しかし、その他の実施形態では、転送されるデータ量を制限するために、特定の１つのコンテナデータに要求を絞ることが望ましい場合がある。
【０１８５】
ＣａｒｄＣｒｅａｔｅＣｏｎｔａｉｎｅｒの間に指定される情報と、この呼出しによって問い合わせることができる情報の間には、少なくとも１：１の関係がある。すなわち、ＣａｒｄＣｒｅａｔｅＣｏｎｔａｉｎｅｒの間に指定されなかったコンテナデータで、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏによってアクセス可能なものはない。
【０１８６】
入力：
ＵｓｅｒＩｄ
Ｐｉｎ
出力：
Ｓｔａｔｕｓ
目的：
供給されたＰＩＮを使って、指定されたユーザ（例えば、ＵｓｅｒまたはＡｄｍｉｎ．）を認証し、ユーザ鍵コンテナなど、カードの秘密データにアクセスする。この呼出しの使用は、ＰＩＮキャッシュライブラリによって規制することができる。
【０１８７】
入力：
ＵｓｅｒＩｄ
ＣｕｒｒｅｎｔＰｉｎ
ＮｅｗＰｉｎ
出力：
Ｓｔａｔｕｓ
目的：
指定されたユーザのＰＩＮを変更する。ベースＣＳＰにおいては、この呼出しは、ＰＩＮキャッシュライブラリによってのみ行うことができる。
【０１８８】
入力：
Ｐｉｎ
出力：
Ｓｔａｔｕｓ
目的：
供給されたＰＩＮを使って、最大許容回数を超えて正しくないユーザＰＩＮが供給されたためにロックされているスマートカードのブロックを解除する。スマートカードがブロックされていなかった場合、あるいは、ブロック解除が失敗した場合には、ステータスにこれらの場合が明記されるはずである。
【０１８９】
公開データ
証明書管理機能に追加して、またはそれに代わるものとして、スマートカード上の汎用ファイルストレージをエミュレートするインタフェースの必要がある場合もある。
【０１９０】
例えば、証明書管理は、列挙、削除、および作成機能を必要とする。このインタフェースは、例えば、従来のＷｉｎｄｏｗｓ（登録商標）のＣｒｅａｔｅＦｉｌｅ、ＲｅａｄＦｉｌｅ、およびＷｒｉｔｅＦｉｌｅの単純化バージョンと同様に見え、また同様に感じられる場合がある。ファイルパスパラメータは、スマートカードの物理レイアウトに論理的にマップすることができる。
【０１９１】
ここで、本発明の特定の例示的態様によれば、ベースＣＳＰからの論理ロケーションの物理カードロケーションへのマッピングは、スマートカード特有モジュール次第である。基本的に、このタイプのインタフェースは、スマートカードを、ベースＣＳＰによって管理される、一般的な汎用ファイルシステムとして抽象化する。
【０１９２】
ベースＣＳＰが、ＣｒｅａｔｅＦｉｌｅセマンティックスを使って、どのように公開カードデータを管理することができるかのという例として、カード上のよく知られたロケーションに記憶されているマスタファイルによる方法が挙げられる。このマスタファイルは、ベースＣＳＰがカードファイルシステム中に記憶しているオブジェクトのディレクトリしての役割を果たすことができる。これによって、ベースＣＳＰは、ユーザ証明書、およびスマートカード上に記憶されているその他のデータに関連付けられたファイル名をルックアップすることができる。したがって、証明書ファイルオブジェクトの内容を、ベースＣＳＰが判断することができる。証明書データには、それに関連付けられた鍵コンテナの位置を突き止めるための情報を含めることができる。しかし、最初にマスタファイルを要求し、次に実際の当該データファイル（例えば、デフォルトユーザ証明書など）を要求するためにさらにスマートカードの読出しが必要になるため、このアプローチにはある程度のトレードオフがある。
【０１９３】
プラス面としては、マスタファイルの使用によって、ベースＣＳＰは、一般的なスマートカードデータをどのように記憶し、またそれにどのようにアクセスするかに対して、十分に制御することができる。特定の実施形態では、これによって、スマートカードの記憶フォーマットのバージョン管理をより容易にすることができ、また、スマートカードをより多用途のものにすることができる。例えば、スマートカードを利用してデフォルトユーザコンテナの名前を追跡するのではなく、単に、その情報をよく知られた汎用ファイルに簡単に記憶することができる。さらなる最適化として、ロード時間にデフォルトファイルを素早くカードから読出してキャッシュするように、ベースＣＳＰを構成することができる。
【０１９４】
入力：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
Ｂｕｆｆｅｒ
ＢｕｆｆｅｒＬｅｎｇｔｈ
出力：
Ｓｔａｔｕｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ
目的：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅによって指定された全ファイルを、ユーザ指定バッファに読み出す。上記において、ＬｏｇｉｃａｌＦｉｌｅＮａｍｅによって指定されたロケーションは、完全修飾されたものであり、かつ、ＦｉｌｅＦｏｒｍａｔにより適切に形成されたものであるべきである。
【０１９５】
ＦｉｌｅＣｏｎｔｅｎｔｓパラメータのデータポインタメンバがＮＵＬＬに設定されている場合、その関数は、指定されたファイルのサイズをＦｉｌｅＣｏｎｔｅｎｓｔｓのデータサイズメンバに入れる。ファイルのサイズがＦｉｌｅＣｏｎｔｅｎｔｓのデータサイズメンバよりも大きい場合には、呼出し側のバッファ中にはどのデータもコピーされず、データサイズメンバはそのファイルのサイズに設定される。ファイルのサイズがＦｉｌｅＣｏｎｔｅｎｔｓのデータサイズメンバよりも小さい場合には、そのファイルが呼出し側のバッファ中にコピーされ、データサイズメンバが、そのファイルのサイズに設定される。
【０１９６】
入力：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ
Ｆｌａｇｓ
出力：
Ｓｔａｔｕｓ
目的：
Ｆｌａｇｓの値に応じて、ファイルが存在しない場合には、そのファイルを作成する。
【０１９７】
入力：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
出力：
Ｓｔａｔｕｓ
目的：
指定されたファイルを削除する。そのファイルが存在しない場合には、返されるステータスは、そのファイルが存在しなかったことを表すはずである。
【０１９８】
入力：
ＥｎｕｍＦｉｒｓｔ｜ＥｎｕｍＮｅｘｔ
Ｉｆ ＥｎｕｍＦｉｒｓｔ， ａ ｄｉｒｅｃｔｏｒｙ ｐｒｅｆｉｘ； ｓｅｅ ｂｅｌｏｗ．出力：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
目的：
ＥＮＵＭ＿ＦＩＲＳＴの場合には、ＬｏｇｉｃａｌＦｉｌｅＮａｍｅパラメータは、ディレクトリプレフィックスを含むことができ、それによって列挙の範囲を制限する。
【０１９９】
入力：
なし
出力：
Ｓｔａｔｕｓ
カードのスペース情報（例えば、残っているバイト数、利用可能な鍵コンテナの数）
目的：
スマートカードの利用可能な記憶スペースの量を求める。これは場合によっては、概算値のことがある。この情報の使用例として、新しい鍵コンテナを作成できるかどうかを判断する場合、および、所与の証明書に十分なストレージをスマートカードが備えているかどうかを判断する場合が挙げられる。前者では、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔのＣＲＹＰＴ＿ＮＥＷＫＥＹＳＥＴを呼び出す際に使用することにより、その呼出しが成功したかどうかを、ＣｒｙｐｔＧｅｎＫｅｙが呼び出されるまで鍵自体は作成されなくても、判断することができる。
Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｏｐｅｒａｔｉｏｎｓ
Ｓｉｇｎ Ｄａｔａ ／ Ｐｒｉｖａｔｅ ｋｅｙ Ｄｅｃｒｙｐｔ
【０２００】
暗号機能の残りの機能は、ベースＣＳＰがパフォーマンスのために実行する場合がある。
入力：
Ｃｉｐｈｅｒｔｅｘｔ
出力：
Ｓｔａｔｕｓ
Ｐｌａｉｎｔｅｘｔ
目的：
解読するための入力データ（ＲＳＡに基づいたデータ、楕円／超楕円暗号法に基づいたデータなど）を、呼出し側が要求したフォーマット（例えばＰＫＣＳ＃１）に基づいて、ベースＣＳＰがパッドすることができる。したがって、例えばＲＳＡベースのカードの場合、ＣａｒｄＰｒｉｖａｔｅＫｅｙＤｅｃｒｙｐｔに、およびそれから渡されるデータは、常に、公開モジュラスと同じ長さである。これによって、カード特有の層は、様々なパディングスキームを実装しなければならない必要から解放される。ベースＣＳＰは、平文においてパディングを検査することができるため、このＡＰＩは、ハードウェアのエラーの場合を除き、成功するはずである。
【０２０１】
入力：
ＡＴ＿ＳＩＧＮＡＴＵＲＥ｜ＡＴ＿ＫＥＹＥＸＣＨＡＮＧＥ
出力：
Ｓｔａｔｕｓ
指定されたアルゴリズムタイプについて、サポートされる鍵サイズ。
目的：
使用されるカードがサポートする公開鍵のサイズを求める。
【０２０２】
データ構造
上記のスマートカード特有の機能のすべてが、共通データ構造を使用することができる。例えば、ＣＡＲＤ＿ＤＡＴＡ構造を定義するために付けられたヘッダを参照されたい。
【０２０３】
実装
カード特有モジュールをプロバイダＤｌｌとして実装することができる。
【０２０４】
上述の方法および装置があれば、スマートカードまたはその他のポータブルデバイスをデータの一般的な記憶にも使用できることがわかるであろう。したがって、スマートカードベンダが、秘密鍵およびそれらに関連付けられた証明書などだけでなく、その他のタイプの資格認定書、特定のアプリケーション、証明書ストアなど、その他の項目に関連するデータの記憶にも使用することができる、汎用スマートカードを提供することを可能にするアーキテクチャが提供される。したがって、上記のモデルをサポートするスマートカードは、おそらく、まだ考慮していない用途においても使用できるであろう。したがって、本明細書で提示している例示的技術は、新たな用途にも適合可能である。
【０２０５】
結論：
本発明の様々な方法および装置のいくつかの例示的実施形態を、添付の図面において例示し、上記の詳細な説明において説明してきたが、本発明は、開示の例示的実施形態に限定されるものではなく、頭記の特許請求の範囲に記載し、それによって定義されている本発明の趣旨から逸脱することなく、多くの再構成、修正、別の形態が可能であることを理解されたい。
【図面の簡単な説明】
【図１】本発明の特定の例示的実施形態で使用するのに適したコンピューティングデバイスを示す構成図である。
【図２】例えば図１に示すようなコンピューティングデバイスで使用するのに適した、ポータブルトークンデバイスのスマートカードとしての実施形態の構成図である。
【図３】スマートカードをコンピューティングデバイスとインタフェースするための、従来のコンピュータソフトウェアアーキテクチャの例示的構成図である。
【図４】本発明の特定の例示的実施形態による、スマートカードおよびその他の同様のデバイスをコンピューティングデバイスにインタフェースするための、改良されたコンピュータソフトウェアアーキテクチャの例示的構成図である。
【符号の説明】
１３０ コンピュータ
１３２ 処理装置（プロセッサ）
１３４ システムメモリ
１３６ バス
１３８ 読出し専用メモリ（ＲＯＭ）
１４０ ランダムアクセスメモリ（ＲＡＭ）
１４２ 基本入出力システム（ＢＩＯＳ）
１４４ ハードディスクドライブ
１４６ 磁気ディスクドライブ
１４８ リムーバブル磁気ディスク（磁気ディスク）
１５０ 光ディスクドライブ
１５２ リムーバブル光ディスク
１５４ ＳＣＳＩインタフェース
１５６ シリアルポートインタフェース（シリアルポート）
１５８ オペレーティングシステム
１６０ アプリケーションプログラム
１６２ その他のプログラムモジュール
１６４ プログラムデータ
１６６ キーボード
１６８ ポインティングデバイス
１７０ インタフェース
１７２ モニタ
１７４ ビデオアダプタ
１７６ リモートコンピュータ
１７８ メモリストレージデバイス
１８０ ローカルエリアネットワーク（ＬＡＮ）
１８２ 広域ネットワーク（ＷＡＮ）
１８４ ネットワークインタフェース（アダプタ）
１８６ モデム
２００ スマートカードリーダ
２０２ スマートカード
２０４ ユニバーサルシリアルバス（ＵＳＢ）ポート（コネクタ）
２０６ ポータブルトークンデバイス（オンボードコントローラまたはプロセッサ）
２０８ オンボードメモリ（メモリ、アクセスメモリ）
３００ ソフトウェアアーキテクチャソリューション
３０２ アプリケーション
３０４ ＣｒｙｐｔｏＡＰＩ
３０６ａ〜ｎ 暗号サービスプロバイダ（ＣＳＰ）
３０８ａ〜ｎ スマートカード（ＳＣ）
４００ ソフトウェアアーキテクチャ
４０４ａ〜ｎ スマートカード特有モジュール
４０２ ベースＣＳＰ
４０６ 管理ＡＰＩ（カード管理ＡＰＩ）
４０８ ＰＩＮマネージャ
４１０ ファイルマネージャ
４１２ コンテナマネージャ
４１４ 暗号マネージャ
【発明の属する技術分野】
本発明は、一般に、コンピューティングデバイスに関し、より詳細には、例えば、異なるタイプのスマートカードなど、異なるタイプのポータブルトークンデバイスを、コンピューティングデバイスに動作可能にインタフェースする際に使用する方法および装置に関する。
【０００２】
【従来の技術】
暗号法は、通例、データが安全に記憶され、かつ／または伝送されるような方法で、データを認証し、符号化し、または暗号化／解読するために利用されている。暗号法は、コンピュータおよびネットワークの数、サイズおよび複雑性が増すにつれ、より一層一般的なものになっている。
【０００３】
一例として、パーソナルコンピュータ（ＰＣ）などのコンピューティングデバイスにおいては、一般に、公開鍵／秘密鍵のペアを使用することにより、通信当事者間で交換されるデータの非対称暗号化を行う。非対称暗号化は、公開鍵暗号化アルゴリズムを使用している。公開鍵アルゴリズムは、２つの異なる鍵（鍵ペアとして知られる）、すなわち、公開鍵と秘密鍵を使用する。これらの２つの鍵は、一般に、それらを数学的に関係付けるきわめて大きな素数から導出される。しかし、実際には、一方の鍵をもう一方から導出することは不可能である。それらの名前が示唆するように、公開鍵は公開され、一方、秘密鍵は秘密にされる。一般的な静的マシンに集中したＰＣ環境においては、秘密鍵が、それを生成したＰＣから離れることは絶対にない場合がある。
【０００４】
鍵の一方で暗号化された情報（すなわちデータ）は、鍵のもう一方でのみ解読することができる。したがって、例えば、秘密鍵で暗号化されたデータは公開鍵でのみ、逆に、公開鍵で暗号化されたデータは秘密鍵でのみ解読することができる。
【０００５】
さらなる安全策として、通信セッションの間、セッション鍵を使用することができる。セッション鍵は、基本的に、通信当事者間で共用される一時的な秘密鍵または秘密である。受信者は、セッション鍵を解読すると、暗号化されているデータを解読することができる。解読したメッセージの保全性は、そのメッセージをハッシュしてメッセージダイジェストを生成し、そのダイジェストの値を、送信者が計算して暗号化メッセージ中に含めたダイジェストと比較することによって確認することができる。
【０００６】
このような暗号法技術に関連する問題の１つは、例えば、通信当事者の公開鍵の１つであると称する公開鍵を不正に差し出すことによって、第三者が通信当事者の一方のなりすましを図る可能性があることである。その通信当事者に宛てられた、その不正な公開鍵によって暗号化されたメッセージまたはハッシュはどれも、その第三者が持っている秘密鍵で解読できると考えられる。
【０００７】
この問題およびその他の問題に対処するために、通信当事者はディジタル証明書を利用することができる。ディジタル証明書は、例えばＶｅｒｉＳｉｇｎ，Ｉｎｃ．など、認証局（ＣＡ）と呼ばれる信頼のおける機関またはエンティティが発行する資格認定書である。この資格認定書は、一般に、公開鍵、およびその証明書の対象者（すなわち、適用される通信当事者）を識別するデータを含む。証明書は、通常、ＣＡがその証明書の対象者を確認し、また、証明書とともに含まれる公開鍵がその対象者に所属するものであることを確認した後でのみ、ＣＡによって発行される。証明書はまた、その証明書が変更されたり偽造されたりしたものではないことを保証するため、ＣＡの公開鍵で署名された、証明書の内容のダイジェストも含む。
【０００８】
ＣＡはまた、本質的に信頼できる自己署名証明書、すなわちルート証明書を提供することもできる。ＣＡは、他のＣＡの階層によってそれ自身を証明することができる。このような情報は、通常、証明書内に含まれている。ディジタル証明書を使って文書およびソフトウェアに署名する場合、この情報が、信頼関係を確立するためにユーザに表示することができる安全かつ確認可能なフォームで、署名された項目とともに記憶される。
【０００９】
長い間には、ディジタル証明書がＰＣ上に蓄積しがちになる。これらのディジタル証明書は、通常、証明書ストアに収集される。一般に、ユーザが、証明書ストア内でディジタル証明書を記憶し、検索し、削除し、列挙し、確認し、または保持することができるようにするツールが、アプリケーションプログラミングインタフェース（ＡＰＩ）機能として提供されている。
【００１０】
これを考慮して、ワシントン州、レッドモンドのＭｉｃｒｏｓｏｆｔ社は、汎用および専用コンピュータ、ＰＣ、ポータブルデバイスなどを含めた、様々な「マシン」で使用するためのソフトウェア、オペレーティングシステム、およびその他のアプリケーションを開発している。Ｍｉｃｒｏｓｏｆｔ社は、暗号サービスを求めるアプリケーションと、このような暗号サービスを提供できるプログラム／デバイスの間の、制御された／拡張可能なインタフェースを提供する暗号ＡＰＩ（以下、「ＣｒｙｐｔｏＡＰＩ」と呼ぶ）を開発した。ＣｒｙｐｔｏＡＰＩ内では、証明書ストア内のディジタル証明書を管理し、また、ディジタル証明書をデータファイルに添付するために使用できるツール（例えば関数）が提供されている。例えば、ＣｒｙｐｔｏＡＰＩは、一般にＣＡによって発行され、もはや有効ではないディジタル証明書が記載された、証明書廃止リスト（ＣＲＬ）を保持している。また、ＣｒｙｐｔｏＡＰＩは、信頼のおけるエンティティが署名した項目を識別する、証明書信頼リスト（ＣＴＬ）もサポートする。証明書ストア内の様々なディジタル証明書、ＣＲＬおよびＣＴＬは、通常、例えばディスクファイルやシステムレジストリなど、マシン内の不揮発性メモリ内に保持されている。
【００１１】
要求された暗号サービスを提供することができる暗号プログラム／デバイスは、マシンに追加されて必要な一意の暗号トークンを提供する、汎用および／または専用のハードウェア／ソフトウェアを含むことができる。したがって、例えば、ＣｒｙｐｔｏＡＰＩは、新規／追加の暗号デバイス／トークンがマシンに追加されることを可能にし、要求しているアプリケーションと追加された暗号デバイス／トークン間のインタフェースとして動作する。このタイプのＡＰＩ機能／インタフェースはよく知られており、例えば、それをはるかに詳細に記載している１９９７年１１月１８日にＳｐｉｅｓらに対して発行された文献もある（例えば、特許文献１参照）。
【００１２】
上述のＡＰＩ機能／インタフェースは、基本的に、暗号デバイスが所定の場所に固定され、常に利用可能であり、ローカルマシンによってのみ使用されることを前提としているため、静的マシンに集中したトークンを使った場合にはうまく動作する傾向がある。しかし、トークンのいくつかがポータブルである場合には、ＡＰＩ機能／インタフェースは必ずしも必要とするトークンの位置を突き止めることができない。
【００１３】
【特許文献１】
米国特許第５，６８９，５６５号明細書
【００１４】
【発明が解決しようとする課題】
その結果、最近のスマートカード（ＳＣ）、およびその他のタイプのポータブルトークン搬送デバイスおよび／またはリムーバブル処理デバイスの人気とともに、設計者は、特定のＳＣなどがＣｒｙｐｔｏＡＰＩで動作できるようにする特定のフォームのインタフェースロジックを提供することが要求されるようになっている。これによっていくつかの問題が生じた。例えば、ＰＣまたはその他の同様のコンピューティングデバイスは、異なるタイプのＳＣをサポートできる必要がある場合には、その異なるＳＣのそれぞれについて、正しいインタフェースロジック、例えばソフトウェアを保持することが必要になる。さらに、多くの場合において明らかになっているように、インタフェースロジックは、構築および設計するのが非常に複雑な場合がある。これらおよびその他の理由から、ポータブルトークンメカニズムおよび／またはその他の同様のリムーバブル／非リムーバブル処理デバイスを、様々な形態のコンピューティングデバイスおよび／または機器内のロジックをサポートする、特定の暗号法に動作可能に結合するための、改良された方法および装置の必要がある。
【００１５】
【課題を解決するための手段】
上述およびその他のニーズは、例えば、本発明の特定の実施形態による装置によって満たされる。その装置は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを含む。このインタフェースロジックは、少なくとも１つの管理機能を暗号提供ロジックに提供する。管理機能は、次の４種類の管理機能、すなわち識別管理機能、ファイル管理機能、コンテナ管理機能、暗号法管理機能のうち少なくとも１つを含む。
【００１６】
その他の実施形態によれば、ある方法が提供される。その方法は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを提供するステップ、および、暗号提供ロジックに動作可能に結合された場合に、識別確認アクティビティ、ファイルアクセスアクティビティ、コンテナアクセスアクティビティ、および暗号アルゴリズムアクティビティを含むアクティビティグループから選択した、少なくとも１つのアクティビティを実行するように、インタフェースロジックを構成するステップを含む。
【００１７】
さらに別の実施形態では、コンピュータ可読媒体の権利を主張する。コンピュータ実行可能命令は、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成することができるインタフェースロジックを確立するステップ、および、識別サポート機能、ファイルアクセスサポート機能、コンテナアクセスサポート機能、および暗号法サポート機能を含むサポート機能グループから選択された少なくとも１つのサポート機能を、インタフェースロジックに確立させるステップを含む動作を、コンピューティングまたはその他の同様のデバイスに実行させることができるコンピュータ可読媒体によって提供される。
【００１８】
本発明の様々な方法および構成を、添付の図面を参照しながら以下の詳細な説明を読むことによって、より完全に理解することができるであろう。
【００１９】
【発明の実施の形態】
概略
以下のセクションでは、様々なコンピューティングデバイスなどにおいて使用するための、例示的な改良された結合／インタフェーススキームを説明する。本発明の特定の態様によれば、この例示的結合／インタフェーススキームを、ハードウェア、ファームウェア、ソフトウェアまたはそれらのいずれかの組合せを含むロジックとして実装することができる。結果として得られるロジックは、例えば、複数の異なるポータブルトークンデバイスおよび／またはその他の同様のリムーバブル／非リムーバブル処理デバイスに、「基礎」レベルのサポートを提供するように構成することができる。その一例がスマートカードである。
【００２０】
以下の説明の多くでは、Ｍｉｃｒｏｓｏｆｔ（登録商標）社のＣｒｙｐｔｏＡＰＩに基づくオペレーティングシステムのサブコンポーネントおよび関連モジュールの既存の特徴を考慮しているが、本発明の範囲はそれよりもはるかに広く、それらに限定されるものではない。例えば、結合／インタフェーススキームおよび技術は、静的トークンとポータブルトークンの両方をサポートする環境における、様々な開発者／ベンダ、および／または彼らの製品の機能、責任、および／または関連する能力に関して、役立つ境界線を定義する。したがって、例示的方法および装置はポータブルであり、またはそうでない場合には、その他の環境、マシン、および／またはオペレーティングシステムに適合可能である。
【００２１】
例示的コンピューティングデバイス構成
図１は、本発明の特定の例示的実施形態による、改良された結合／インタフェーススキームおよび技術に適し、かつ／またはそれらをサポートするコンピュータ１３０の一般的な例を示す例示的構成図である。様々なタイプのコンピューティングデバイスが、これらのスキームおよび技術から恩恵を得ることができる。したがって、「マシン」という用語を、それらのスキームおよび技術の全てまたは一部を実施することが可能な、いずれかのタイプのデバイスまたは機器を表すためにも使用することがしばしばある。
【００２２】
図１を参照すると、コンピュータ１３０は、１つまたは複数の処理装置１３２、システムメモリ１３４、および、システムメモリ１３４を含めて、様々なコンポーネントをプロセッサ１３２に結合するバス１３６を含む。バス１３６は、様々なバスアーキテクチャのいずれかを使った、メモリバスまたはメモリコントローラ、周辺バス、アクセラレイティッドグラフィックスポート、およびプロセッサまたはローカルバスを含めた、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。システムメモリ１３４は、読出し専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などに、コンピュータ１３０内のエレメント間の情報の転送を援助する、基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２は、ＲＯＭ１３８に記憶されている。
【００２３】
コンピュータ１３０は、ハードディスク（図示せず）からの読出し、およびそれへの書込みのためのハードディスクドライブ１４４、リムーバブル磁気ディスク１４８からの読出し、およびそれへの書込みのための磁気ディスクドライブ１４６、および、ＣＤ−ＲＯＭやその他の光媒体などのリムーバブル光ディスク１５２からの読出し、およびそれへの書込みのための光ディスクドライブ１５０をさらに含む。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０は、ＳＣＳＩインタフェース１５４または特定のその他の適切なインタフェースによって、バス１３６に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストレージを、コンピュータ１３０に提供する。本明細書に記載の例示的環境は、ハードディスク、リムーバブル磁気ディスク１４８、およびリムーバブル光ディスク１５２を利用しているが、当業者は、例示的動作環境においては、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など、コンピュータがアクセス可能なデータを記憶することができるその他のタイプのコンピュータ可読媒体も使用できることを理解されたい。
【００２４】
ハードディスク、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０上には、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、およびプログラムデータ１６４を含めて、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード１６６およびポインティングデバイス１６８などの入力デバイスを介して、コマンドおよび情報をコンピュータ１３０に入力することができる。その他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらおよびその他の入力デバイスは、バス１３６に結合されたインタフェース１７０を介して、処理装置１３２に接続される。モニタ１７２またはその他のタイプの表示デバイスも、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続される。パーソナルコンピュータは、一般に、モニタに加えて、スピーカおよびプリンタなど、その他の周辺出力デバイス（図示せず）を含む。
【００２５】
コンピュータ１３０は、一般に、リモートコンピュータ１７６などの１台または複数のリモートコンピュータへの論理接続を使った、ネットワーク化された環境で動作する。リモートコンピュータ１７６は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードであってよく、図１にはメモリストレージデバイス１７８しか示していないが、一般に、コンピュータ１３０に関連して上記に説明したエレメントの多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１８０および広域ネットワーク（ＷＡＮ）１８２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいては一般的である。
【００２６】
コンピュータ１３０は、ＬＡＮネットワーキング環境で使用される場合は、ネットワークインタフェースまたはアダプタ１８４を介してローカルネットワーク１８０に接続される。コンピュータ１３０は、ＷＡＮネットワーキング環境で使用される場合は、一般に、モデム１８６、または、インターネットなどの広域ネットワーク１８２を介して通信を確立するためのその他の手段を含む。モデム１８６は内蔵でも外付けでもよく、シリアルポートインタフェース１５６を介してバス１３６に接続される。ネットワーク化された環境においては、パーソナルコンピュータ１３０に関連して示すプログラムモジュール、またはそれらの一部を、リモートのメモリストレージデバイスに記憶することができる。図示のネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立するためのその他の手段も使用できることを理解されたい。
【００２７】
一般に、コンピュータ１３０のデータプロセッサは、コンピュータの様々なコンピュータ可読記憶媒体中に、異なる時間に記憶された諸命令によってプログラムされる。一般に、プログラムおよびオペレーティングシステムは、例えばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布され、それらから、コンピュータの補助メモリ中にインストールまたはロードされる。実行時、それらは、少なくとも一部が、コンピュータの主電子メモリ中にロードされる。本明細書に記載の発明は、マイクロプロセッサまたはその他のデータプロセッサと関連して、下記に説明するステップを実施するための命令またはプログラムを含む場合の、これらおよびその他の様々なタイプのコンピュータ可読記憶媒体を含む。本発明はまた、下記に記載の方法および技術に従ってプログラムされている場合のコンピュータ自体も含む。
【００２８】
説明のために、本明細書では、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントを別個のブロックとして説明するが、このようなプログラムおよびコンポーネントは、様々な時点で、コンピュータの異なるストレージコンポーネントに存在し、また、コンピュータのデータプロセッサによって実行されることを理解されたい。
【００２９】
トークンの可搬性、およびアプリケーションプログラム１６０をサポートする、関連する暗号機能をサポートするために、コンピュータ１３０は、少なくとも１つのポータブルトークンインタフェースをさらに含む。例えば、適用可能なトークンデータ／命令で符号化されている場合には、磁気ディスク１４８または光ディスク１５２をトークンキャリアまたはデバイスとみなすことができる。しかし、さらに将来は、ポータブルトークンインタフェースが、コンピュータ１３０への追加ハードウェアの結合を含む可能性がある。したがって、図示のように、例えば、スマートカードリーダ２００を、シリアルポート１５６などのポートを介して、バス１３６に接続することができる。スマートカードリーダ２００は、その他の入出力デバイスと同様に、アプリケーションプログラムおよび／またはその他のモジュールによってサポートされる。スマートカードリーダ２００は、スマートカード２０２を受けて、スマートカード２０２を処理装置１３２に動作可能に結合するように構成される。スマートカードリーダ２００は、複数のスマートカードをサポートすることができる。当業者は、その他のタイプ／形態のポータブルトークン、および／またはその他の同様のリムーバブル／非リムーバブル処理メカニズムが、その他のインタフェースデバイスを利用できることを理解されよう。
【００３０】
さらなる例によれば、適用可能であれば、ユニバーサルシリアルバス（ＵＳＢ）ポート２０４をバス１３６に結合して、スマートカードリーダおよび／またはその他のタイプのポータブルトークンデバイス２０６をサポートすることができる。ポータブルトークンデバイスの基本的概念は、暗号機能をサポートするために必要とされる場合には、ユーザがそれを１つまたは複数のコンピュータシステムに供給できるということである。リムーバブル／非リムーバブル処理メカニズムの基本的概念も同じであり得るが、ただし、製造者またはその他の技術者／管理者によってデバイスまたは機器中に構成されたスマートカードの場合のように、特定の実施形態ではそのメカニズムを実質的に永久的に構成することができる点が異なる。一例として、セットトップボックスまたはその他のデバイス内に埋め込まれ、通常は消費者が取り外すことはない加入者カードが挙げられる。
【００３１】
例示的ポータブルトークンおよび／またはその他の同様の処理デバイス
図２は、例示的スマートカード２０２を示す構成図である。図示のように、スマートカード２０２は、オンボードコントローラまたはプロセッサ２０６に結合されたコネクタ２０４を含む。プロセッサ２０６は、さらにオンボードメモリ２０８に結合されている。メモリ２０８は、一般に、データの損失なしにスマートカード２０２をマシンからマシンに移動させることが可能な、不揮発性メモリである。プロセッサ２０６は、スマートカード２０２に電源が投入されると、メモリ２０８および／またはコンピュータ１３０によって与えられる命令に応答可能になる。
【００３２】
この構成の場合、暗号鍵にかなりのセキュリティを提供するように、スマートカードを構成することができる。ユーザがスマートカード２０２によって提供されるサービスを起動、またはそれらにアクセスしようとすると、さらなるセキュリティまたは識別データ（例えば、個人識別番号（ＰＩＮ）またはストリング、個人的および／またはその他の生物測定学上の情報／データ）をコンピュータ１３０に入力するようにユーザに要求することにより、さらなるセキュリティを提供することができる。例えば、カード所有者は、ＰＩＮを入力して秘密鍵を起動すること、または指紋をスキャンさせることが要求される場合がある。例えばトークンキャリアとして、スマートカード２０２は、好ましくは、少なくとも１組の非対象鍵ペアを保持する。対象鍵は、コンピュータ１３０のより強力な処理装置１３２によって処理されることが好ましい。
【００３３】
スマートカードの開発者は、通常、自分が望むように、自由にスマートカードを開発／プログラムし、また、以前に定義されたインタフェースは複雑でエラーを発生し易いため、これらのスマートカードへのインタフェースにおいて問題が発生する場合がある。現在、スマートカードには、物理インタフェースレベルを超えるスタンダードはほとんどない。カリフォルニア州、レッドウッドシティのＲＳＡ研究所から入手可能な、公開鍵暗号法スタンダード＃１１：暗号トークンインタフェーススタンダードが、現在、ポータブルトークンの使用を規定するためのドラフト段階にある。しかし、現在のドラフト中で提案されている解決策／インタフェースは、本明細書で記載しているような、様々なオブジェクトおよびメソッドの呼出し技術を使ったクリーン／汎用インタフェースを提供しない。
【００３４】
さらに、インタフェースレベルを超える指定スタンダードはどれも、それぞれが自分達自身の要件、スタンダードおよびプラクティスを持っている可能性があるスマートカードベンダにとっては逆効果であるというのが、一般的なコンセンサスであるように思われる。
【００３５】
本発明の特定の態様によれば、このような様々なデバイスの製造者および実装者のプランおよび／または要望が、非常に必要とされ、ロバストに実装可能な結合／インタフェーススキーマおよび技術によって考慮され、サポートされる。本発明の特定のさらなる態様によれば、必要不可欠なインタフェースをサポートするための重要なコードを開発する負担は、基本的に、オペレーティングシステムおよび／またはそのサブコンポーネントの開発者にシフトされている。
【００３６】
従来のソフトウェアアーキテクチャソリューション
図３を参照する。図３は、１つまたは複数のアプリケーション３０２と、１つまたは複数のスマートカード３０８ａ〜ｎ間のインタフェースを提供するために実装された、従来のソフトウェアアーキテクチャソリューション３００の例示的な一部を示す構成図である。
【００３７】
この例では、呼び出しているアプリケーション３０２とスマートカード３０８ａ〜ｎの間の従来のインタフェースは、呼び出しているアプリケーション３０２をサポートするように動作可能に構成された暗号ＡＰＩ３０４を含む。インタフェースは、１つまたは複数の暗号サービスプロバイダ（ＣＳＰ）３０６ａ〜ｎをさらに含む。この例では、一意の異なるスマートカード３０８ａ〜ｎのそれぞれについて、対応するＣＳＰ３０６ａ〜ｎがある。
【００３８】
従来、各スマートカード３０８ａ〜ｎは特定のデータおよび／またはデータ交換、および関数の呼出しを必要とするため、信頼できるＣＳＰ３０６ａ〜ｎを開発することは、きわめて困難であることがわかっている。様々なソフトウェア開発者またはその他の同様のベンダは、通常、インタフェース内の彼らそれぞれのロジックに対する責任を負うため、そのような努力はさらに複雑化されている。したがって、例えば、図３では、ベンダ１をスマートカード（ＳＣ１）３０８ａおよび対応するＣＳＰ１３０６ａを提供するものとして図示してあり、一方、ベンダ０は暗号ＡＰＩ３０４を提供する。経験により、暗号ＡＰＩ３０４を考慮して、またその他の（おそらくまだ決定されていない）スマートカードリーダ、スマートカード、および対応するＣＳＰも考慮してロバストＣＳＰ１３０６ａを生産するために、ベンダ１に負わされる負担は大きすぎる可能性があることがわかっている。
【００３９】
したがって、インタフェース操作、および様々なスマートカードおよび同様のデバイスの機能を分析した結果、スマートカードベンダに負わされている負担を実質的に低減する、改良された設計が得られた。さらに、本明細書で提示する、結果として得られた結合／インタフェーススキームおよび技術は、複数の専用／限定用途インタフェースではなく、より標準化された、または汎用のインタフェースを提供する。
【００４０】
改良されたソフトウェアアーキテクチャソリューション
図４を参照する。図４は、本発明の特定の例示的実施形態による、改良されたソフトウェアアーキテクチャ４００を示す構成図である。
【００４１】
ここで、ソフトウェアアーキテクチャ４００は、１つまたは複数のスマートカード（ＳＣ）３０８ａ〜ｎおよび／またはその他の同様のデバイスのサービス／機能を要求し、かつ／または使用するように構成可能な、１つまたは複数のアプリケーション３０２を含む。図３に示すように、アプリケーション３０２は、暗号ＡＰＩ３０４に動作可能に結合されている。暗号ＡＰＩ３０４とＳＣ３０８ａ〜ｎの間の動作は、ベースＣＳＰ４０２であり、必要に応じて、１つまたは複数のスマートカード特有モジュール４０４ａ〜ｎである。さらに、この実施形態では、ベースＣＳＰ４０２とともに、１つまたは複数の管理ＡＰＩ４０６が含まれている。
【００４２】
特定の例示的態様によれば、ベースＣＳＰ４０２によって提供される機能には、ＳＣ３０８ａ〜ｎの少なくとも一部に共通である、１つまたは複数のインタフェースサポート機能が含まれる。例として、特定の実施形態では、ベースＣＳＰは、少なくとも４種類の共通インタフェースサポートアクティビティ、すなわち、ＰＩＮ管理、ファイル管理、コンテナ管理、および暗号操作を提供／サポートする。ＳＣ３０８ａ〜ｎのそれぞれは、特定の時点で、このようなアクティビティおよび／またはインタフェース機能を必要とするプロセスに関与するため、これらのインタフェースサポートアクティビティは、「汎用カテゴリ」を表すとみなすことができる。
【００４３】
したがって、図４では、ベースＣＳＰ４０２は、ＰＩＮマネージャ４０８、ファイルマネージャ４１０、コンテナマネージャ４１２、および暗号マネージャ４１４の機能を含む。これらの管理モジュールは、スマートカードベンダがより容易に対話することができ、また恩恵を引き出すことができる、十分に定義されたインタフェースを提供するように構成されている。したがって、本発明の特定の実施形態によれば、ベースＣＳＰ４０２は、暗号機能、および、スマートカードによって提供されるデータストレージ、スマートカードおよびその機能を発見し、それらにアクセスする際のＣｒｙｐｔｏＡＰＩの機能などのその他の機能を動作可能にサポートする、「ミニドライバ」として動作するように構成される。
【００４４】
ＰＩＮマネージャ４０８、ファイルマネージャ４１０、コンテナマネージャ４１２、および／または暗号マネージャ４１４を使って、ベースＣＳＰ４０２は、スマートカード３０８ａ〜ｎが提供できる様々な適用可能な特徴を提示する。暗号ＡＰＩ３０４とスマートカード３０８ａ〜ｎの両方が、それらの開発者やベンダなどに関係なく、ベースＣＳＰ４０２によって提供される定義済みインタフェース機能セットを有する。モジュラーの論理構成においては、追加される新しい／異なるスマートカード３０８ａ〜ｎのそれぞれは、ベースＣＳＰ４０２によって提示された共通機能の使用法をそのときにのみ必要とするだけである。スマートカード３０８ａ〜ｎは、せいぜい、スマートカードロジックとベースＣＳＰ４０２の間で交換された情報を、必要に応じて変換または処理するスマートカード特有モジュールを提供する必要があるだけである。さらに、本発明の特定の実施形態によれば、ベースＣＳＰを、暗号ＡＰＩ３０４の大幅な変更が必要ないように、あるいは全く変更する必要がないように設計することができる。さらに、１つまたは複数のカード管理ＡＰＩ４０６を、スマートカード３０８ａ〜ｎ、および場合によっては暗号ＡＰＩ３０４に、新規／追加サポートを提供するように実装することができる。
【００４５】
ＰＩＮマネージャ４０８は、例えば、ユーザが、自分がスマートカードを使用する認可を受けたユーザであることをスマートカードに納得させるために、必要な情報を入力するログオン操作などの、識別機能をサポートするように構成される。したがって、例えば、特定の実施形態では、ベースＣＳＰが、ユーザを認証するために使用できる、証明書、ＲＳＡ呼出しなど、ユーザのＰＩＮまたはその他の同様の情報の受信／処理をサポートする。一例では、ＰＩＮを使って、カードに対してユーザを認証することができる。カードに対して認証されると、ユーザは、次いで、カード上のＲＳＡ秘密鍵を使って、自分自身をシステムに対して認証させることができる。一般に、ユーザが自分自身をシステムに対して認証させるためには、証明書も必要とされる。したがって、スマートカード上にその証明書を記憶すると便利である。これらおよびその他の様々な信頼のおける認証技術などはよく知られており、したがって、それらについての詳細な説明は本明細書の範囲外である。
【００４６】
したがって、暗号ＡＰＩ３０４が、暗号の関連付けを行い、またはコンテキストを作成することによって、その後、アプリケーション３０２が、スマートカード３０８ａ〜ｎによって提供される暗号機能およびその他の機能を利用できるようにする際に、暗号ＡＰＩ３０４を援助するようにＰＩＮマネージャ４０８を構成することができる。このような機能および／またはその他の機能を遂行するために、ＰＩＮマネージャ４０８は、１つまたは複数のＡＰＩを含むことができる。
【００４７】
本発明の特定の例示的実施形態によれば、ファイルマネージャ４１０は、アクセスメモリ２０８（例えば図２参照）およびその中に提供されているデータファイルおよび／またはファイル構造を発見し、かつ／またはそれらにアクセスする機能を、アプリケーション３０２に提供するように構成される。多くの場合、スマートカード３０８ａ〜ｎは、メモリおよび／またはその中に記憶されているデータファイルのすべてまたは選択された一部に対するそのようなアクセスを、許可／不許可することができる可能性がある。特定の実施形態では、このような構成は、多くのオペレーティングシステムでは一般的な、読出し、書込み、および／または消去の許可など、特定ファイルへのアクセス許可を含むことができる。したがって、このような機能および／またはその他の機能を遂行するために、ファイルマネージャ４１０は、１つまたは複数のＡＰＩを含むことができる。
【００４８】
本発明の特定の実施形態によれば、コンテナマネージャ４１２は、コンテナおよび／またはそれらの内容、あるいは、スマートカード３０８ａ〜ｎに関連づけられ、少なくとも一時的にメモリ２０８中で保持される、その他のコンテナ関連の情報について、発見、アクセス、および／または制御を行うように構成される。本明細書で使用しているように、コンテナという用語は、一般に、代表的にはオブジェクトベースまたはその他の同様のロジックの設計（例えば、ソフトウェアプログラミング方法）において提供される、１つまたは複数のオブジェクトを指す。コンテナは、一般に、１つまたは複数のオブジェクトを論理的に含む。コンテナは空のことがある。コンテナはまた、他のコンテナを含むことができる。コンテナマネージャ４１２は、アプリケーション３０２、暗号ＡＰＩ３０４、および／またはスマートカードがこのようなコンテナのアクティビティを実行する際に、それをサポートすることができる。例えば、コンテナを使って、公開鍵／秘密鍵のペアを記憶することができる。これは、しばしば、鍵コンテナと呼ばれる。コンテナマネージャ４１２は、１つまたは複数のＡＰＩを含むことができる。
【００４９】
その他の特定の実施形態では、スマートカード（またはその他の同様のデバイス）がそのロジック、機能、データの記憶、コンテナ、証明書、鍵などを管理できるように、さらなる管理ＡＰＩ４０６が提供される。このような追加およびオプションのＡＰＩを、特に、１つまたは複数のスマートカードをサポートするように構成することができる。
【００５０】
本発明の特定の例示的実施形態によれば、暗号マネージャ４１４は、暗号操作のためのインタフェースサポートを提供するように構成される。一例では、暗号マネージャ４１４を、１つまたは複数の鍵ペア、アルゴリズム、証明書などを利用することができる、スマートカード３０８ａ〜ｎの暗号ロジックによって、データの暗号化、解読、ハッシュ、メッセージのダイジェスト、署名などをサポートするように構成することができる。暗号マネージャ４１４はまた、１つまたは複数のＡＰＩを含むこともできる。
【００５１】
例示的スマートカードインタフェースの構成
このセクションでは、本発明のさらなる特定の実施形態による、さらなる例示的実施形態の詳細を提供する。ここでの目的は、本発明の範囲を限定することではなく、さらに他の実施形態に適合させることが可能な、特定の実施形態に特有の特徴および技術を紹介することである。
【００５２】
このことを念頭に置いて、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム、およびその中に提供されているＣｒｙｐｔｏＡＰＩで使用するための例示的スキームおよび技術を提供する。ここでは、ベースＣＳＰを、ＣｒｙｐｔｏＡＰＩ、および必要に応じて、１つまたは複数のスマートカード特有モジュールで動作するように提供する。さらなる例示的実施形態に従って、オプションのスマートカード管理ＡＰＩについても説明する。特定の実施形態においては、これらのスマートカード管理ＡＰＩの１つまたは複数は、ベースＣＳＰを除いても有益であることを認識されたい。
【００５３】
この構成およびその他の同様の構成の基本的な設計目標は、スマートカードまたはその他の同様の処理／ロジック構成の飛躍的なパフォーマンス、セキュリティ、およびロバスト性を提供することである。この例では、ベースＣＳＰおよび／または管理ＡＰＩが、スマートカード、ＣｒｙｐｔｏＡＰＩ、および呼び出しているアプリケーションの動作可能な結合／インタフェースのニーズを、完全に、またはそのほとんどをサポートする基盤を提供するように設計される。上述のように、ベースＣＳＰおよび管理ＡＰＩは、有利には、ＣｒｙｐｔｏＡＰＩを介してアプリケーションをサポートする必要が生じる可能性がある、様々なタイプのスマートカードおよび／またはその他の同様のデバイスの、全部ではないがほとんどにおいて共通であり、かつ／または共通であると期待される特定の機能に対する、必要なサポートを提供する。
【００５４】
この例では、ＣｒｙｐｔｏＡＰＩは、スマートカード特有の機能から抽出されたものである。したがって、ＣｒｙｐｔｏＡＰＩは、アプリケーション／スマートカード間のインタフェース中に第１のレベルを形成する。例えば、特定のＡＰＩは、様々なスマートカードまたはその他の同様のデバイスの利用法のシナリオを完全にサポートするように、このレベルにおいて提供される。ベースＣＳＰは、この例示的アプリケーション／スマートカード間のインタフェース中に第２のレベルを形成する。特定の実施形態では、スマートカード管理ＡＰＩはまた、この第２のレベルに常駐する。アプリケーション／スマートカード間のインタフェースの第３のレベルは、必要に応じて、１つまたは複数のスマートカード特有モジュールを含む。ここで、スマートカード特有のモジュールは、ベンダ特有の、およびカード特有の実装依存性から抽象化される可能性が高い。このようなスマートカード特有モジュールは、例えば、１つまたは複数のカード特有ＡＰＩによって定義される。
【００５５】
この例では、共通のスマートカード機能には、ＰＩＮで保護される可能性が高い、秘密鍵の記憶（少なくとも１つの秘密鍵について）が含まれる。秘密鍵は、このように、「デフォルト」の鍵コンテナ内に記憶することができる。この例で実施しているように、たった１つの鍵が提供／許可される場合には、それは鍵交換タイプである。スマートカードの機能にはまた、少なくとも１つのスマートカードのログオン証明書の記憶も含まれる。ここで、例えば、証明書は、公開読出し可能で、ＰＩＮによる書込み保護を施すことができる。
【００５６】
この例では、共通のスマートカード機能には、複数の証明書および／または鍵のサポートも含まれる。複数の鍵を記憶することもできる。「デフォルト」の鍵コンテナを与えることが役立つ場合もあるが、各秘密鍵は、関連する鍵コンテナ名を持つことができる。各秘密鍵は、例えば、鍵タイプ（例えば、署名、鍵交換など）など、それに関連付けられた１組のプロパティを備えることができる。その他の例示的な鍵のプロパティには、鍵の寿命、鍵のサイズ、および／または関連する証明書および公開鍵の識別情報が含まれる。
【００５７】
複数の証明書を、可能には異なる使用法で、記憶することができる。特定の実施形態では、秘密鍵ごとに複数の証明書をサポートすることが望ましい場合がある。各証明書は、基本的に、関連付けられた秘密鍵にそれをリンクする、識別情報を有することができる。
【００５８】
共通機能には、スマートカードの公開データ部分中に記憶することができるルート証明書も含めることができる。このルートへのアクセスは、ユーザの公開証明書データにアクセスする場合と同じはずである。ルート証明書は、ＭｉｃｒｏｓｏｆｔルートやＶｉｓａルートなど、ユーザの主要信頼ポイントであってよい。このような機能は、ユーザプロファイル、したがってユーザのルートストアを、ユーザが利用することができない、または修正することができない環境においては役立つ場合がある。その一例が、キオスクにおけるサーバの認証である。
【００５９】
スマートカード上で、汎用証明書ストア機能も共通にすることができる。これは、全般的なカードの記憶が増大するにつれて一層役立つようになる場合がる。ユーザは、例えば、全ルートストアをカード上に保持するように、あるいは一部のＣＡ（認証局）証明書を保持するように決めることができる。
【００６０】
データの再方向付けも、別の潜在的な共通機能である。ここで、例えば、スマートカードの公開データ部分は、ＵＲＬまたは、ユーザの個人データの残りの部分を識別する、同様のものを含むことができる。この機能の興味深い使用法には、ユーザデータの集中型記憶が含まれる。この場合、これには、ユーザの証明書、カード上に記憶された鍵で暗号化された「あまり重要ではない」秘密鍵、アドレス帳データなどを含めることができる。
【００６１】
ＣｒｙｐｔｏＡＰＩの挙動、およびアプリケーション／スマートカード間のインタフェース構成５００が満たすニーズをよりよく理解するためには、スマートカードに関連する使用法のシナリオを考えてみることが役立つ。以下のカード使用法シナリオは、クライアントデバイス上においてそれぞれのスマートカードのユーザ操作が実行されたときからの、ベースＣＳＰの追跡に基づいたものである。
【００６２】
２つの例示的シナリオは、スマートカードのログオン、およびスマートカードユーザの登録を含む。以下の追跡のそれぞれは、所与のシナリオで使用されるＣｒｙｐｔｏＡＰＩの呼出し、および、もしあれば、そのＡＰＩコールの結果生じる、その後のスマートカード操作から成る。
【００６３】
ログオン開始プロセス：
【表１】
−このコンテナはすでに開かれているため、キャッシュデータを使用する。
【００６６】
【表２】
証明書伝搬プロセスの開始：
ＣｒｙｐｔＤｅｓｔｒｏｙＫｅｙ
ＣｒｙｐｔＤｅｓｔｒｏｙＨａｓｈ
ＣｒｙｐｔＲｅｌｅａｓｅＣｏｎｔｅｘｔ
Ｐｉｎ Ｃｈａｎｇｅ
【００６８】
【表３】
ユーザの登録：
電子署名
【００７１】
【表４】
例示的ＣｒｙｐｔｏＡＰＩ操作
ＣＰＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
特定の実施形態では、ＡｃｑｕｉｒｅＣｏｎｔｅｘｔを呼び出すことによって、そのようなデータをできるだけ早くキャッシュするように、ＣＳＰＱｕｅｒｙＣａｐａｂｉｌｉｔｉｅｓ、ＣＳＰＱｕｅｒｙＦｒｅｅＳｐａｃｅ、およびＣＳＰＱｕｅｒｙＫｅｙＳｉｚｅｓ関数が呼び出される。次の例示的シナリオでは、指定されたコンテナを備えたスマートカードが見つかると、例えば、コンテキストフラグ、コンテナ名、対応するスマートカードのシリアル番号、スマートカードにキャッシュされているデータへのポインタ、スマートカード選択ヒューリスティックス、および／またはコンテナ指定レベルなど、ユーザのコンテキストデータを使って、新しいＨＣＲＹＰＴＰＲＯＶが作成される。
【００７３】
ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔの呼出しに応答して、ベースＣＳＰは、呼出し側が指定したコンテナを、特定のカード／リーダにマッチさせようと試みる。呼出し側は、例えば、以下に記載するように、様々なレベルの特有性でコンテナ名を与えることができ、そのコンテナ名は、より特有な要求からより特有ではない要求の順に、すなわち、リーダ名およびコンテナ名、リーダ名およびデフォルトコンテナ（例えばＮＵＬＬ）、コンテナ名のみ、および／またはデフォルトコンテナ（例えばＮＵＬＬ）のみの順でソートされる。一般に、リーダ名が提供される最初の２つの場合については、ベースＣＳＰは、指定されたリーダをサーチして、そのリーダに挿入されているスマートカード上で、要求された操作を実行する。リーダ名が提供されない次の２つの場合には、ベースＣＳＰは、現在の要求に適したカード／リーダについて、命令されたサーチを実行する。この場合、ベースＣＳＰにすでにわかっているスマートカードから開始して、現在わかっているすべてのスマートカード／リーダへと続く。上記のそれぞれの場合について、ベースＣＳＰを、例えば、キャッシュされているカードデータのリスト中で、マッチするスマートカードをサーチするように構成することができる。したがって、このようなキャッシュは、ベースＣＳＰがそれまでに遭遇したスマートカードのリスト、および関連するカード状態情報を含むことができる。一般に、マッチするスマートカードがキャッシュ中に見つかった場合には、そのキャッシュ項目に関連するスマートカードハンドルをテストすることができる。これは、スマートカードが依然としてリーダ中にあるかどうかを判断するための１つの方法である。
【００７４】
コンテナ操作
この例示的実施形態では、コンテナ操作を、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔによって要求することができる。例えば、コンテナ操作は、新しいコンテナの作成（ＣＲＹＰＴ＿ＮＥＷＫＥＹＳＥＴ）、既存のコンテナを開くこと、および／またはコンテナの削除（ＣＲＹＰＴ＿ＤＥＬＥＴＥＫＥＹＳＥＴ）を含むことができる。ユーザコンテキストを特定のスマートカードおよびリーダに関連付けるために使用されるヒューリスティックスは、要求されたコンテナ操作、および使用されたコンテナ指定のタイプまたはレベルに基づくことができる。
【００７５】
ここで、コンテナ作成操作を、例えば以下のように制限することができる。
【００７６】
サイレントコンテキストなし−鍵コンテナの作成では、常に、例えばＰＩＮプロンプトなどのユーザインタフェース（ＵＩ）を示すことができなければならない。
【００７７】
既存のコンテナを上書きしない−指定したコンテナが選択したスマートカード上にすでに存在する場合は、別のスマートカードを選択するか、その操作を失敗する（これは、カード指定のタイプまたはレベルによることが可能）。
【００７８】
以下の例示的コンテキストフラグを利用することができる。
ＣＲＹＰＴ＿ＳＩＬＥＮＴ−この場合、例えば、この操作の間、ＵＩは何も表示されない。
ＣＲＹＰＴ＿ＭＡＣＨＩＮＥ＿ＫＥＹＳＥＴ−例えば、この操作の間、キャッシュされているデータは何も使用されない。
ＣＲＹＰＴ＿ＶＥＲＩＦＹＣＯＮＴＥＸＴ−例えば、カード上の公開データにのみアクセスすることができる。
【００７９】
「コンテナ操作」および「コンテナの指定」に加えて、上記のＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔフラグなど、カード選択の間のその他のユーザオプションについても考慮しなければならない。
【００８０】
カード選択の挙動
特定の例示的シナリオでは、ユーザは、スマートカードを挿入するように促される。ユーザコンテキストがサイレントの場合には、この操作は失敗し、ＵＩは何も表示されない。そうでない場合には、ユーザは、ＵＩに応答して、スマートカードを挿入するか、またはおそらく「キャンセル」をクリックすることができる。ユーザがキャンセルすると、操作は失敗する。
【００８１】
特定のコンテナ指定を使うと、指定したリーダ中のスマートカードのみをマッチの対象とみなすことができるので、スマートカード選択プロセスの複雑さを低減することができる。したがって、例えば、ベースＣＳＰは要求されたリーダを見つける。それが見つからない場合には、プロセスは失敗する。リーダ中にスマートカードがなかった場合には、例えばＵＩを介して、スマートカードを挿入するようユーザを促すように、ベースＣＳＰを構成することができる。
【００８２】
リーダ中にスマートカードが挿入され、動作可能に接続されると、ベースＣＳＰは、選択されたスマートカード上のデフォルトコンテナの名前の判断を支援する。例示的なコンテナ操作には、例えば、既存のコンテナを開くこと、コンテナの削除、および／または指定されたコンテナを見つけることが含まれる。指定されたコンテナがスマートカード上に見つけられなかった場合には、再び、カードを挿入するように、特定の方法でユーザを促すことができる。新しいコンテナを作成するときに、指定されたコンテナがスマートカード上にすでに存在していた場合には、プロセスは失敗する。
【００８３】
本発明のさらなる特定の態様によれば、該当するスマートカードをユーザコンテキストにマッチさせるように、ベースＣＳＰを構成することができる。与えられた基準を満たす、キャッシュされているスマートカードは複数存在する可能性があるため、これは有益である。
【００８４】
特定の実施形態では、ベースＣＳＰにわかっている各スマートカードは、特定の方法で記憶されている（例えば、プロセス全体にわたって、すでにアクセスされたカードのリストをキャッシュすることができる）。既存のコンテナを開くために、ベースＣＳＰは、識別された（例えば指定された）コンテナ名を、スマートカードのコンテナ名のキャッシュ中で探す。コンテナ名は、デフォルトコンテナを指定する、ＧＵＩＤまたはＮＵＬＬの場合がある。キャッシュされているＳＣＡＲＤＨＡＮＤＬＥに対して、そのフレッシュネスを確認するための操作が試みられる。
【００８５】
キャッシュされているカードが取り外され、コンテキストがサイレントであると判断された場合には、ベースＣＳＰは、別のマッチするスマートカードをサーチし続けることができる。キャッシュされているスマートカードが取り外され、コンテキストが非サイレントである場合には、ユーザにスマートカードの挿入を促すＵＩを表示することができる。ユーザがＵＩ内の「キャンセル」をクリックすると、ベースＣＳＰはマッチするカードをサーチし続けることができる。ベースＣＳＰのキャッシュ中にマッチするカードが見つからない場合には、例えば、適切な（ａｐｐｒｏｐｒｉａｔｅ）コールバックフィルタを用いてＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄ（）呼出しを使うことにより、要求されたコンテナを備えた、マッチするカードを見つけることができる。ＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄに提供されたコールバックは、列挙された各カードについて、ベースＣＳＰキャッシュのエントリを作成する。
【００８６】
コールバックは、遭遇したスマートカードのそれぞれについて、新しいスマートカードキャッシュエントリを作成し、それを、ベースＣＳＰのグローバルリストまたはその他の同様のデータ構造中に入れる。カードキャッシュ構造では、提供されたＳＣＡＲＤＨＡＮＤＬＥおよび新しいＰＩＮキャッシュハンドルを保持するために、新しいカード特有データ構造を作成することができる。
【００８７】
この例示的構成においては、ユーザにＰＩＮを催促する場合には、コンテナ作成においてＣＲＹＰＴ＿ＳＩＬＥＮＴが許可されない。この場合、カード選択のＵＩが必要なことがある。その他の操作については、呼出し機能は、デフォルトコンテナに対して「確認」コンテキストを得、次いで、ＣｒｙｐｔＳｅｔＰｒｏｖＰａｒａｍを呼び出して、その後の操作のためにユーザＰＩＮをキャッシュすることができる。しかし、コンテナ作成の場合には、このような操作を実行する対象となるコンテナがまだない場合がある。
【００８８】
ベースＣＳＰにすでにわかっている各カードについて、記憶されているＳＣＡＲＤＨＡＮＤＬＥをリフレッシュすることができる。以下のチェックを行うこともできる。すなわち、スマートカードが除去されている場合にはサーチを続ける。また、スマートカードが依然として存在するが、すでに指定されたコンテナを備えている場合には、サーチを続ける。また、スマートカードが利用可能であるが、ＣＳＰＱｕｅｒｙＣａｒｄＦｒｅｅＳｐａｃｅの呼出しによって、カードにさらなる鍵コンテナのための十分な記憶がないことが示された場合には、サーチを続ける。そして、それ以外の場合には、上記の基準を満たす最初の利用可能なスマートカードを、コンテナ作成のために使用することができる。
【００８９】
マッチするスマートカードがベースＣＳＰキャッシュ中に見つからない場合には、列挙されたカードをフィルタにかけるために使用するコールバックを利用して、候補スマートカードがまだ指定されたコンテナを備えていず、また、ＣＳＰＱｕｅｒｙＦｒｅｅＳｐａｃｅが、そのカードが追加コンテナ用の十分なスペースを有することを示していることを確認することができる。適切なカードが何も見つからない場合には、スマートカードを挿入するようユーザを促すＵＩを表示することができる。
【００９０】
コンテナの削除を試みるときに、指定されたコンテナ名がＮＵＬＬである場合には、プロセスは失敗する。これは、特定のリーダが指定されていない、曖昧な場合であるとみなすことができる。
【００９１】
すでにベースＣＳＰにわかっているスマートカードのそれぞれについて、記憶されているＳＣＡＲＤＨＡＮＤＬＥをリフレッシュして、以下のチェックを行うことができる。すなわち、スマートカードが指定されたコンテナを備えていない場合には、サーチを続ける。また、コンテキストがサイレントであり、スマートカードが指定されたコンテナを備えているが、取り外されている場合には、サーチは失敗する。また、コンテキストが非サイレントであり、スマートカードが指定されたコンテナを有しているが、取り外されている場合には、スマートカードを挿入するようユーザに促すＵＩを表示することができる。また、マッチするスマートカードがベースＣＳＰのキャッシュ中に見つからない場合には、列挙カードをフィルタにかけるために使用されるコールバックを使って、候補カードが指定されたコンテナを備えていることを確認する。また、コンテキストが非サイレントであり、適切なスマートカードが見つからない場合には、スマートカードを挿入するようユーザに促すＵＩを表示することができる。そして、その他の場合には、プロセスは失敗する。
【００９２】
本発明の特定の実施形態によれば、以下のＡＰＩが定義される。
【００９３】
【表５】
ＰＣＳＰ＿ＰＲＯＶ＿ＣＴＸとして初期化する。
ｐｓｚＣｏｎｔａｉｎｅｒ
【００９５】
呼出し機能は、例えば、完全修飾されたコンテナロケーションまたは単純なコンテナ名のいずれかを指定することができる。前者は、リーダ名とコンテナ名の両方を含むことができる。ベースＣＳＰは、完全修飾されたコンテナがあるかどうかに応じて、異なるセマンティックスを使用して適切なカードの位置を突き止めるように構成することができる。
【００９６】
【表６】
呼出し側の要求が有効であることを確認する。
【００９８】
鍵タイプ−サポートされる鍵タイプは、ＡＴ＿ＳＩＧＮＡＴＵＲＥおよびＡＴ＿ＫＥＹＥＸＣＨＡＮＧＥである。
【００９９】
鍵サイズ−ＣＳＰＥｎｕｍＫｅｙＳｉｚｅｓ（）を呼び出して、指定された鍵サイズが有効であることを確認する。鍵サイズが指定されていない場合には、その機能によって返されたデフォルト鍵サイズを使用することができる。
【０１００】
鍵コンテナ−ユーザコンテキスト中に指定されているコンテナがすでに存在し、要求されたタイプの鍵を備えており、また、コンテキストがサイレントである場合には、プロセスは失敗する。そうでない場合には、その鍵の置換えをユーザに確認するためのＵＩが表示される。次いで、ＣＳＰＣｒｅａｔｅＣｏｎｔａｉｎｅｒ（）を呼び出して、例えば、鍵作成フラグ、コンテナ名、鍵サイズなどを指定することができる。
【０１０１】
【表７】
【表８】
スマートカードインタフェース層
本発明の特定の態様によれば、ＰＣＳＣと暗号法の関連はこのレベルまで抽象化され、この場合、カードデータのキャッシングおよび論理カードファイルシステムのフォーマットを処理することができる。
【０１０４】
スマートカードインタフェース操作
スマートカードインタフェース操作を行う目的の１つは、カード特有操作と、直接、ベースＣＳＰが行う機能呼出しの間の密結合を確立することである。特定の場合においては、カードインタフェース操作は、カード特有操作からできるだけ多くの一般コードを取り除き、カードデータのキャッシュ層としての役割を果たすことである。一般に、スマートカードから読み出すことができるデータはどれも、ベースＣＳＰプロセス中に記憶することができる。その後、そのデータに対する要求があると、キャッシュされたコピーのフレッシュネスがチェックされ、次いで、適切な場合にはそれが使用される。スマートカードインタフェース操作は、キャッシュされたデータが利用可能でない場合にのみ、カード特有操作を呼び出す。これは、スマートカードとの通信はきわめて遅くなりがちなため、有利である。一方、キャッシュされているデータはどれも、使用する前にその妥当性を確認することが重要である。確認しない場合、スマートカードに基づいた認証のセキュリティが危うくなる可能性がある。キャッシュのフレッシュネスチェックがこの問題を解決する。
【０１０５】
証明書の列挙
特定の実施形態では、「証明書読出し」操作において、コンテナの識別を指定し、対応する証明書の位置を突き止めるように、ベースＣＳＰを構成することができる。この場合、証明書の列挙はなく、コンテナの列挙があるだけである。もちろん、すべてのコンテナが証明書を持っているわけではない。２つまたはそれ以上の証明書の間で鍵を共用することが望ましい場合もある。そのために、コンテナの列挙に加えて、証明書の列挙をサポートする必要がある場合がある。
【０１０６】
証明書の列挙は、ファイルフィルタ中で「ＵｓｅｒＣｅｒｔ」というプレフィックスを指定することにより、ＣＳＰＥｎｕｍＦｉｌｅｓを呼び出すことによって行うことができる。証明書については、デフォルト鍵コンテナに属するものが何かあれば、証明書のファイル名ＧＵＩＤがコンテナのＧＵＩＤ名と同じ場合がある。一般に、証明書については、１つの鍵について複数の証明書をサポートするように、対応する鍵コンテナの名前を、記憶されている証明書データ中に含めることができる。しかし、証明書とその鍵コンテナが、必ずしも同じＧＵＩＤ名を共用する必要はない。
【０１０７】
例示的スマートカード機能
【０１０８】
【表９】
鍵コンテナ
鍵コンテナ名を、論理カードファイル名として指定することができる。すなわち、リーダ名とコンテナ名の両方を指定する、完全修飾されたコンテナ名は、カードインタフェースの機能には渡されないはずである。適用可能なＡＰＩのそれぞれを、スマートカードのコンテキスト情報を受け取るように構成することができるため、完全修飾された名前のコンテナ名部分を渡すことはできる。
【０１１０】
【表１０】
【表１１】
例示的暗号操作
特定の実施形態によれば、データパディングを利用することができる。ＲｓａＥｎｃｒｙｐｔのような関数を使って、データパディングを処理してスマートカードにディスパッチするか、または、要求された公開鍵をスマートカードから抽出することができる。スマートカードが公開鍵のエクスポートをサポートしている場合には、例えば、ＲＳＡ暗号化操作、カーブに基づいた暗号化操作、および／または同様のものをサポートするように、ベースＣＳＰを構成することができる。特定の例示的実施形態によれば、ベースＣＳＰは、公開鍵のエクスポートをサポートしないカードを「サポート」しない。この場合、公開鍵は、それらのそれぞれのコンテナデータとともにキャッシュすることができる。
【０１１３】
【表１２】
カードインタフェースのキャッシング
特定の実施形態では、スマートカードがリムーバブルなので、「ライトスルー」キャッシュスキームが利用されている。このスキームでは、最後の書込み者が勝ち取る。ベースＣＳＰは、データの矛盾のために書込み操作を失敗するように要求されることはない。例えば、プロセスＢが最後にＸを読み出してから、プロセスＡが項目Ｘをスマートカードに書き込んでいる場合がある。プロセスＢは、その後、Ｘを書き込む可能性があり、その場合、これは、プロセスＡ中にキャッシュされているＸを、矛盾しているとみなす。この状況を緩和するために、キャッシュには、リーダが一貫したデータを得られるようにするための助けとなる、タイムアウト（機能停止）を設けるべきである。様々なタイプのデータに対して異なるタイムアウトを使用することが可能である。
【０１１５】
キャッシュの実装は、例えば、よく知られたカード上のロケーションに記憶されている、１組のカウンタに基づくことが可能である。このカウンタは、書込み操作を行っているベースＣＳＰが、インクリメントすることができる。カウンタの値は、キャッシュデータによって正しく反映されている、カード状態への最後の修正を識別する。簡単にするために、限定された細分性で、修正を追跡することができる。例として、以下のカードエリアを、それぞれを全体として、キャッシュによって追跡することができる。［コンテナ｜データファイル｜ＰＩＮ］。
【０１１６】
別の例では、プロセスがスマートカードのデータファイルのいずれかを修正した場合に、カード上の「データファイル」のキャッシュロケーションを、現在のタイムスタンプで更新することができる。いずれかのデータファイルに対する、いずれかの他のプロセスからの、いずれかのその後の読出し操作は、キャッシュミスになる。これは、要求されたファイルがすでに正しくキャッシュされている場合でも、最後の操作の後で別のカード上のファイルが修正されたならば、その要求されたファイルをカードから直接、読み出さなければならないことを意味する。
【０１１７】
よく知られたカード上のキャッシュのロケーションは、予め決定された名前を有する特定のデータファイルのことがある。したがって、例えば、キャッシュの状態の更新を、このよく知られたファイル名を使って、ＣａｒｄＲｅａｄＦｉｌｅおよびＣａｒｄＷｒｉｔｅＦｉｌｅ操作によって行うことができる。キャッシュの状態を正しく保持するために必要とされるカードとの対話量を低減するために、キャッシュデータを、それ以外のいずれかのデータなしに、それ自身の論理ファイル中に記憶することができる。これによって、ベースＣＳＰは、カードから最低必要量のデータの読出しおよび書込みを行って、キャッシュの状態を保持することができる。
【０１１８】
本発明の特定の実施形態によれば、カードのキャッシュファイルの内容は、予め定義された構造である。スマートカードを取り外した場合、例えば、そのスマートカードがシリアル番号を使って初期化されている場合には、スマートカードのキャッシュが、ベースＣＳＰをロードしたプロセス中に安全に残っていることが可能である。スマートカードを再挿入した場合、スマートカードのシリアル番号がマッチし、キャッシュファイルが変更を示さないならば、すでにキャッシュされているデータはフレッシュであるとみなすことができる。
【０１１９】
初期化
ログオンなど、重要な操作の間の応答時間を改善するための最適化として、特定のデータをスマートカードから予め読み出し、キャッシュしておくことができる。例えば、このようなキャッシングは、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔを呼び出す間に発生し得る。予め読み出すためのスマートカードデータの例としては、いずれかのよく知られたカードデータファイルの内容が挙げられる。これには、カードのシリアル番号およびデフォルトのコンテナ名が含まれる場合がある。したがって、証明書はスマートカード上に記憶されている１つまたはそれ以上のデータ項目であることが多いので、例えば、この時点で、カードからユーザの証明書のいずれかを読み出すと有利である。実際、特定の実施形態では、そうすることによって、ログオンを相当スピードアップさせることができる。ユーザログオンまたは認証プロセス（例えば、Ｗｉｎｌｏｇｏｎ）などのカードクライアントは、このメカニズムを賢明に使って、例えば、ユーザがＰＩＮを入力している間にユーザのスマートカードデータをプレロードする。
【０１２０】
データの書込み
キャッシュの更新は、トランザクションに基づくことが可能であり、キャッシュの更新を必要としている、すぐ前の操作と同じトランザクション内で行うことができる。現在、スマートカードの実装は、一般に、ロールバックできないミューテックスであるため、スマートカードのトランザクションは、技術的には誤称である。しかし、ミューテックスが解除される前に、キャッシュ状態の更新およびカードデータの更新の両方がその順番で行われる。この例を以下に示す。そこでは、ベースＣＳＰがＦｏｏと呼ばれる一般的なデータファイルをカードに書き込んでいる。
【０１２１】
【表１３】
データの読出し
ベースＣＳＰからのスマートカードへの読出し要求のそれぞれにおいてＣａｃｈｅＦｉｌｅをカードから読み出すことができる。当該のデータエリアが修正されていない場合（例えば、汚れていない場合）には、可能であれば、キャッシュデータが読出し要求を満たすことがある。当該のデータエリアが汚れている場合、または要求されたデータがキャッシュされていない場合には、カードの読出しが実際に行われて、その結果がキャッシュされる。
【０１２３】
例として、特定の実施形態では、スマートカード中の機能を、呼び出されたときに以下の動作を行うように構成することができる。これらの動作は、キャッシュの保全性を保証するという目的にかない、結果的にスマートカードへの呼出回数を低減する。
ａ）ベースＣＳＰが、当該のスマートカードについて作成した、キャッシュされた項目をルックアップする
ｂ）そのような項目が存在しない場合には、ｆＩｓＣａｃｈｅｄ＝Ｆａｌｓｅである。
ｃ）そうでない場合には、ｆＩｓＣａｃｈｅｄ＝Ｔｒｕｅである。項目のキャッシュスタンプを得る。それをｍｙＣａｃｈｅＳｔａｍｐと呼ぶ。
ｄ）このＳＣＡＲＤＨＡＮＤＬＥ上でトランザクションを開始する。
ｅ）ＣａｒｄＲｅａｄＦｉｌｅ（）を使って、キャッシュファイルを読み出す。
ｆ）キャッシュファイル中のどの値が所望のカードデータ項目（コンテナ、一般データ、またはＰＩＮ）に対応するかを判断する。これをｃｕｒｒｅｎｔＣａｃｈｅＳｔａｍｐと呼ぶ。
ｇ）ｆＩｓＣａｃｈｅｄがＦａｌｓｅ、またはｃｕｒｒｅｎｅｔＣａｃｈｅＳｔａｍｐ＞ｍｙＣａｃｈｅＳｔａｍｐである場合には、適切なカード特有モジュール（例えばＡＰＩ）によって、要求されたデータ項目をスマートカードから読み出す。
ｈ）そうでない場合には、キャッシュデータを使用する。
ｉ）このＳＣＡＲＤＨＡＮＤＬＥ上でのトランザクションを終了する。
ｊ）スマートカードから項目を読み出さなければならない場合には、新しいデータでキャッシュを更新し、ｃｕｒｒｅｎｔＣａｃｈｅＳｔａｍｐをその新しいデータに関連付ける。
ｋ）要求されたデータを呼出し側に返す。
【０１２４】
スマートカードのキャッシングシナリオ
セッションを通じて、ほぼ最低限のデータ量だけをスマートカードから読み出すことが賢明である場合がある。これは、変更されていないデータをスマートカードから２度読み出すべきではないことを意味する。そうではなく、変更されていないデータは、常に、ベースＣＳＰのカードデータのキャッシュから検索されるべきである。この場合、例えば、セッションを、ベースＣＳＰをロードして、所与のスマートカード上で操作を実行するプロセスの存在期間であるとみなすことができる。
【０１２５】
セッションを通じて、スマートカードのキャッシュはほぼ一貫している。すなわち、例示的ベースＣＳＰを使用した場合、正しくない、期限切れのデータをキャッシュから読み出すことはできない。その他のプロセスが同じスマートカードにアクセスしている場合にさえ、それが言える。
【０１２６】
シナリオ＃１−ユーザログオンのための初期ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
入力：
Ｎａｍｅｄ Ｒｅａｄｅｒ
Ｄｅｆａｕｌｔ Ｃｏｎｔａｉｎｅｒ
【０１２７】
キャッシュされているスマートカードのリストをサーチする。何も見つからない。
【０１２８】
ＳＣａｒｄＵＩＤｌｇＳｅｌｅｃｔＣａｒｄ（）によって、スマートカードを列挙する。このＡＰＩに渡されるコールバックが、リーダ名をフィルタにかける。
【０１２９】
このカードのためのＣＡＲＤ＿ＤＡＴＡ構造が作成されて、ベースＣＳＰにわかっているカードのリストに追加される。これは、ＣＳＰのカードリストキャッシュ中の最初の項目である。
【０１３０】
このカードのシリアル番号について、ＣＳＰＲＥＡＤＦＩＬＥ（）を呼び出す。まだシリアル番号がキャッシュされていないので、この結果、ＣａｒｄＲｅａｄＦｉｌｅ（）が呼び出される。
【０１３１】
このカードのデフォルトコンテナの名前について、ＣＳＰＲｅａｄＦｉｌｅ（）を呼び出す。まだコンテナ情報がキャッシュされていないので、この結果、ＣａｒｄＲｅａｄＦｉｌｅ（）が呼び出される。
【０１３２】
このコンテナについて、ＣＳＰＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）を呼び出す。現在キャッシュされているコンテナ情報がそのコンテナの名前であるため、この結果、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）が呼び出される。
【０１３３】
シナリオ＃２−ユーザログオンのための第２のＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔ
入力：
Ｎａｍｅｄ Ｒｅａｄｅｒ
Ｎａｍｅｄ Ｃｏｎｔａｉｎｅｒ
【０１３４】
指定されたコンテナを探して、キャッシュされているカードのリストをサーチする。それがキャッシュ中に見つかる。キャッシュされているＳＣＡＲＤＨＡＮＤＬＥをテストして、それが依然として有効であることを確認する。
【０１３５】
そのシリアル番号について、ＣＳＰＲｅａｄＦｉｌｅ（）を呼び出す。キャッシュされている値が見つかる。キャッシュ読出しプロセスは、この項目のキャッシュスタンプに基づいて、そのキャッシュされているデータが最新であることを確認する。特定の実施形態では、サニティチェックとして、カードからのこの値を再度読み出すことができる。これは、ＧＵＩＤコンテナ名がすでにマッチしている場合には必要ない。
【０１３６】
指定されたコンテナ名について、ＣＳＰＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏｒ（）を呼び出す。キャッシュされているデータが見つかる。キャッシュ読出しプロセスは、そのキャッシュデータが最新のものであることを確認する。
【０１３７】
ファイルフォーマット
完全修飾された論理ファイル名、例えば、ベースＣＳＰとスマートカード特有モジュールの間に基礎を置くタイプは、論理ディレクトリ名、およびその後に続く論理ファイル名から成る。したがって、この例では、「ＤｉｒＮａｍｅ／ＦｉｌｅＮａｍｅ」というパターンになる。ここで、スマートカード特有モジュールは、論理ファイル名を物理カードロケーションにマップする必要がある。
【０１３８】
例示的論理ディレクトリ名
次の論理ディレクトリ名、すなわち、ＲｏｏｔＣｅｒｔ、ＵｓｅｒＣｅｒｔ、およびＧｅｎｅｒａｌＤａｔａは、予め定義することができる。
【０１３９】
例示的論理ファイル名
うまく形成された論理ファイル名は、以下の規則に従っている場合がある。
【０１４０】
ユーザ証明書については、論理ファイル名を、ＧＵＩＤ、および情報を識別する２、３バイトをそれに加えたもので構成する。これは、最大約３７＋３＝４０バイトになる。
【０１４１】
ルート証明書については、論理ファイル名を、公開鍵のハッシュで構成する。これは、ユーザの信頼情報に対する高速クエリを可能にする。
【０１４２】
一般的なカード上のデータについては、論理ファイル名をシリアル番号で構成する。ユーザのデフォルトコンテナ名を表すマスタファイルなど、共通の一般的なデータファイルは、前もって定義されたシリアル番号を有する。
【０１４３】
例示的証明書
一例では、証明書を、以下のデータ構造の形でスマートカード上に記憶することができる。
【０１４４】
【表１４】
キャッシュファイルのよく知られた名前は、以下のようになるはずである。
”ＧｅｎｅｒａｌＤａｔａ＼ＣａｃｈｅＦｉｌｅ”
＃ｄｅｆｉｎｅ ＣＡＲＤ＿ＣＡＣＨＥ＿ＦＩＬＥ ”ＧｅｎｅｒａｌＤａｔａ＼ＣａｃｈｅＦｉｌｅ”
【０１４６】
キャッシュファイルの内容は、以下の構造のみで構成される。
【０１４７】
【表１５】
キャッシュファイルの例示的デフォルトアクセス制御リスト（ＡＣＬ）は以下の通りである。
Ｅｖｅｒｙｏｎｅ Ｒｅａｄ， Ｗｒｉｔｅ
Ｓｅｒｉａｌ Ｎｕｍｂｅｒ Ｆｉｌｅ
【０１４９】
シリアル番号ファイルは、カードのシリアル番号を含む。よく知られた名前は以下のようになるはずである。
シリアル番号ファイルの内容は、以下の構造のみで構成される。
シリアル番号ファイルのデフォルトＡＣＬは以下の通りである。
デフォルトコンテナファイルは、スマートカードのデフォルトコンテナのＧＵＩＤを含む。よく知られた名前は以下のようになり得る。
デフォルトコンテナファイルの内容は、以下の構造を含む。
ｐｓｚＤｅｆａｕｌｔＣｏｎｔａｉｎｅｒ中に指定されているＧＵＩＤは、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏ（）、ＣａｒｄＰｒｉｖａｔｅＫｅｙＤｅｃｒｙｐｔ（）などの呼出しにおいて直接、使用することができるような方法でフォーマットすることができる。記憶されているＧＵＩＤは、もしあれば、デフォルト鍵コンテナに対応する、デフォルトユーザ証明書の名前も意味する。指定された証明書ファイルにアクセスするには、例えば、ＣａｒｄＲｅａｄＦｉｌｅを呼び出して、返されたＧＵＩＤの前に「ＵｓｅｒＣｅｒｔ＼」を付加して構成したファイル名を指定する。
【０１５５】
デフォルトコンテナファイルのデフォルトＡＣＬは以下の通りである。
カードストレージエリアは、適切なデフォルトＡＣＬで構成すべきである。
【０１５７】
【表１６】
【表１７】
例示的なスマートカード取り外し技術
ここで、スマートカードインタフェースは、例えば、スマートカード特有モジュールからのスマートカードの取り外しの通知にロバストに応答することができるはずである。スマートカード特有モジュールが、スマートカードが取り外されたことを検出した場合には、適切なステータスが返されるはずである。これに応答して、スマートカードインタフェースは、スマートカードに再接続を試みることができる。再接続が成功した場合には、スマートカード特有操作を再度試みるはずである。再接続が失敗すると、そのステータス通知をベースＣＳＰから伝搬することができる。
【０１６０】
ＳＣＡＲＤＨＡＮＤＬＥは、スマートカードインタフェースからスマートカード特有操作に渡されるデータ中に含めることができる。そのハンドルを呼び出した結果、ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤがスマートカードインタフェースに返される。この事例が処理され得る呼出しのリストには、すべてのスマートカード特有操作に、トランザクション開始操作を加えたものが含まれる。
【０１６１】
ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤに応答して、カードインタフェースは、上記によって、復元、再接続、および再試行を試みることができる。これは、スマートカードが再挿入されているかどうかをチェックするためのものである。ベースＣＳＰによるスマートカードの最初期化が失敗し、現在のユーザコンテキストがサイレントではない場合には、ベースＣＳＰは、スマートカードを再挿入するようにユーザを促すＵＩを表示することができる。現在のユーザコンテキストがサイレントである場合、または、ユーザがＵＩ操作において「キャンセル」した場合には、現在のＣｒｙｐｔｏＡＰＩ機能は、ＳＣＡＲＤ＿Ｗ＿ＲＥＭＯＶＥＤ＿ＣＡＲＤで失敗する。
【０１６２】
例示的ベースＣＳＰユーザインタフェース
上述のように、特定の状況においては、ユーザと対話するためにベースＣＳＰが必要とされる場合がある。特定の例示的実施形態では、ベースＣＳＰによって提供されるＵＩは以下のように動作する。
【０１６３】
ベースＣＳＰは、現在のユーザコンテキストがサイレントとして取得されなかった場合、ＵＩを表示することができる。
【０１６４】
ベースＣＳＰによって表示される全てのダイアログは、キャンセルボタンを含む。ユーザが「キャンセル」を押すと、その影響を受けたＣｒｙｐｔｏＡＰＩによって、該当するエラーコードが返される。
【０１６５】
全てのダイアログは、ユーザが入力を行う、どのスマートカード、どの操作などに関して、可能な限り具体的である。
【０１６６】
例示的シナリオ
ユーザコンテキストがサイレントではない場合、ベースＣＳＰは、次のような状況においてＵＩを表示することができる。
【０１６７】
スマートカードの初期化が失敗した場合には、要求されたスマートカードを挿入するようユーザを促す。
【０１６８】
現在挿入されている以外のスマートカードに関連するユーザコンテキストについて、ＣｒｙｐｔｏＡＰＩ操作が要求された場合には、要求されたスマートカードを挿入するようユーザを促す。
【０１６９】
カード特有操作がＰＩＮキャッシュの要求を行った場合には、現在の操作に対してキャッシュされているＰＩＮが正しくない可能性がある。ＳＣＡＲＤ＿Ｗ＿ＷＲＯＮＧ＿ＣＨＶというステータスを、カードインタフェースに返すことができる。応答して、ユーザは、正しいＰＩＮを入力するように促されることがある。その場合、ＰＩＮのキャッシュは更新され、次いで、カード特有操作が再度、試みられる。
【０１７０】
例示的実施形態
可能であれば、スマートカードにはフレンドリな名前を与えるべきである。これは、ＵＩメッセージテキスト中に含めることができる。このフレンドリな名前は、カードの個別化の間に送達することができ、また「ドメインユーザログオンカード」など、比較的一般的なものであってよい。あるいは、スマートカードのシリアル番号を表示することができる。ただし、ユーザが所与のシリアル番号を実際のスマートカードに関連付けることは難しい場合もある。
【０１７１】
合衆国では、ベースＣＳＰパッケージの暗号署名は、ある種の輸出規制を受けるため、ベースＣＳＰのリソースストリングを、ベースＣＳＰ自体とは別のパッケージで配布することができる。
【０１７２】
この例示的ベースＣＳＰでは、以下の２つの別個のダイアログボックスを使用することができる。
カード挿入ダイアログ−このダイアログは、タイトルバー、テキストボックス、およびキャンセルボタンを含むことができる。
ＰＩＮダイアログ−このダイアログは、タイトルバー、テキストボックス、編集ボックス、ＯＫボタン、およびキャンセルボタンを含むことができる。
【０１７３】
スマートカード特有モジュール
この例示的実施形態におけるスマートカード特有モジュールは、標準化された１組のマクロレベル操作を実行して、論理カードファイルシステムオブジェクトを物理カードロケーションにマップするように設計されている。ここで、例えば、各スマートカード特有操作は、単一のアトミックトランザクションを実施する。
【０１７４】
例示的カード特有操作
カード機能
特定の実施形態では、ベースＣＳＰが、特定のスマートカードおよび／またはスマートカード特有モジュールの複数の変形形態をサポートすることが必要な場合がある。所与のスマートカードの機能を利用するために、スマートカード特有モジュールは、スマートカードが提供する１組の機能全てに問い合わせを行うためにベースＣＳＰが使用することができる、ＡＰＩを含むことができる。スマートカードの機能の例には、圧縮アルゴリズムおよびチェックサムによるファイルの保全性の保証が含まれる。圧縮など、ベースＣＳＰが必要とするいずれかの機能がスマートカードによって提供される場合、ベースＣＳＰは、スマートカードによる実行を利用することができる。そうでない場合には、ベースＣＳＰは、この機能を自分自身で実行することができる。
【０１７５】
【表１８】
入力：
バージョン番号をｐＣａｒｄＣａｐａｂｉｌｉｔｉｅｓ中に設定する。
出力：
Ｓｔａｔｕｓ
Ｆｉｌｌｅｄ−ｉｎ ｐＣａｒｄＣａｐａｂｉｌｉｔｉｅｓ ｓｔｒｕｃｔ
目的：
例えば、圧縮およびファイルのチェックサムなど、このレベルで提供される機能について、スマートカードとスマートカード特有モジュールの組合せに問い合わせる。
【０１７７】
【表１９】
この例では、コンテナごとに２つの鍵ペアがサポートされる。各鍵には、鍵の使用法、署名、または鍵交換が関連付けられている。その他の特定の実施形態では、単一の鍵ペアまたは２組より多い鍵ペアをサポートすることができる。
【０１７９】
特定の実施形態では、各鍵コンテナに、スマートカード上の対応する証明書に関する識別情報（例えば、証明書データをどこで見つけたらよいかに関する論理情報）を関連付けることもできる。全てのコンテナが対応する証明書を備えるわけではない。これは、鍵ごとに複数の証明書がサポートされるわけではないことを前提にしている。
【０１８０】
Ｆｉｒｓｔ｜Ｎｅｘｔ
出力：
Ｓｔａｔｕｓ
現在の鍵コンテナのＧＵＩＤ名
目的：
連続する呼出しにおいて、スマートカード上に存在する全ての鍵コンテナの名前をリストする。列挙の最後まで到達しても、出力バッファの内容が変わっていない場合には、ステータスは失敗を表すはずである。
【０１８１】
ＧＵＩＤ
出力：
Ｓｔａｔｕｓ
目的：
ＧＵＩＤによって指定された鍵コンテナを削除する。コンテナが存在していて、無事に削除された場合には、ステータスは成功を表すはずである。そうでない場合には、ステータスは、コンテナが存在しなかったこと、または特定の理由で削除が失敗したことなどを表すはずである。
【０１８２】
ＫｅｙＧｅｎ｜ＫｅｙＩｍｐｏｒｔ
ＧＵＩＤ
ＫｅｙＧｅｎの場合には、鍵のタイプおよびサイズも供給されなければならない。
ＫｅｙＩｍｐｏｒｔの場合には、鍵データも供給されなければならない。
出力：
Ｓｔａｔｕｓ
目的：
ＧＵＩＤという名前の新しい鍵コンテナを作成する。この新しいコンテナは、呼出しが成功した場合には、常に有効な鍵を含む。新しいコンテナを作成する２通りの方法は、ランダムな鍵の生成による方法、および既存の鍵データのインポートによる方法である。
【０１８３】
デフォルトコンテナがすでに署名鍵を有するときに、アプリケーションが、デフォルトコンテナを使用し、鍵交換の鍵を利用して証明書を作成することを試みた場合、このプロセスは、コンテナがすでに「一杯」であり、現在の鍵が正しく使用されていないために、１鍵モデルにおいては失敗する。正しい挙動は、そのプロセスを新しい／異なるコンテナに再方向付けすることである場合がある。
【０１８４】
ＧＵＩＤ
出力：
Ｓｔａｔｕｓ
Ｄａｔａ
目的：
指定された鍵コンテナに、その鍵のタイプ（例えば、署名または鍵交換）など、それが含む鍵に関する追加情報を問い合わせる。その挙動は、全ての入手可能なコンテナ情報を返すことであることが可能である。しかし、その他の実施形態では、転送されるデータ量を制限するために、特定の１つのコンテナデータに要求を絞ることが望ましい場合がある。
【０１８５】
ＣａｒｄＣｒｅａｔｅＣｏｎｔａｉｎｅｒの間に指定される情報と、この呼出しによって問い合わせることができる情報の間には、少なくとも１：１の関係がある。すなわち、ＣａｒｄＣｒｅａｔｅＣｏｎｔａｉｎｅｒの間に指定されなかったコンテナデータで、ＣａｒｄＧｅｔＣｏｎｔａｉｎｅｒＩｎｆｏによってアクセス可能なものはない。
【０１８６】
ＵｓｅｒＩｄ
Ｐｉｎ
出力：
Ｓｔａｔｕｓ
目的：
供給されたＰＩＮを使って、指定されたユーザ（例えば、ＵｓｅｒまたはＡｄｍｉｎ．）を認証し、ユーザ鍵コンテナなど、カードの秘密データにアクセスする。この呼出しの使用は、ＰＩＮキャッシュライブラリによって規制することができる。
【０１８７】
ＵｓｅｒＩｄ
ＣｕｒｒｅｎｔＰｉｎ
ＮｅｗＰｉｎ
出力：
Ｓｔａｔｕｓ
目的：
指定されたユーザのＰＩＮを変更する。ベースＣＳＰにおいては、この呼出しは、ＰＩＮキャッシュライブラリによってのみ行うことができる。
【０１８８】
Ｐｉｎ
出力：
Ｓｔａｔｕｓ
目的：
供給されたＰＩＮを使って、最大許容回数を超えて正しくないユーザＰＩＮが供給されたためにロックされているスマートカードのブロックを解除する。スマートカードがブロックされていなかった場合、あるいは、ブロック解除が失敗した場合には、ステータスにこれらの場合が明記されるはずである。
【０１８９】
公開データ
証明書管理機能に追加して、またはそれに代わるものとして、スマートカード上の汎用ファイルストレージをエミュレートするインタフェースの必要がある場合もある。
【０１９０】
例えば、証明書管理は、列挙、削除、および作成機能を必要とする。このインタフェースは、例えば、従来のＷｉｎｄｏｗｓ（登録商標）のＣｒｅａｔｅＦｉｌｅ、ＲｅａｄＦｉｌｅ、およびＷｒｉｔｅＦｉｌｅの単純化バージョンと同様に見え、また同様に感じられる場合がある。ファイルパスパラメータは、スマートカードの物理レイアウトに論理的にマップすることができる。
【０１９１】
ここで、本発明の特定の例示的態様によれば、ベースＣＳＰからの論理ロケーションの物理カードロケーションへのマッピングは、スマートカード特有モジュール次第である。基本的に、このタイプのインタフェースは、スマートカードを、ベースＣＳＰによって管理される、一般的な汎用ファイルシステムとして抽象化する。
【０１９２】
ベースＣＳＰが、ＣｒｅａｔｅＦｉｌｅセマンティックスを使って、どのように公開カードデータを管理することができるかのという例として、カード上のよく知られたロケーションに記憶されているマスタファイルによる方法が挙げられる。このマスタファイルは、ベースＣＳＰがカードファイルシステム中に記憶しているオブジェクトのディレクトリしての役割を果たすことができる。これによって、ベースＣＳＰは、ユーザ証明書、およびスマートカード上に記憶されているその他のデータに関連付けられたファイル名をルックアップすることができる。したがって、証明書ファイルオブジェクトの内容を、ベースＣＳＰが判断することができる。証明書データには、それに関連付けられた鍵コンテナの位置を突き止めるための情報を含めることができる。しかし、最初にマスタファイルを要求し、次に実際の当該データファイル（例えば、デフォルトユーザ証明書など）を要求するためにさらにスマートカードの読出しが必要になるため、このアプローチにはある程度のトレードオフがある。
【０１９３】
プラス面としては、マスタファイルの使用によって、ベースＣＳＰは、一般的なスマートカードデータをどのように記憶し、またそれにどのようにアクセスするかに対して、十分に制御することができる。特定の実施形態では、これによって、スマートカードの記憶フォーマットのバージョン管理をより容易にすることができ、また、スマートカードをより多用途のものにすることができる。例えば、スマートカードを利用してデフォルトユーザコンテナの名前を追跡するのではなく、単に、その情報をよく知られた汎用ファイルに簡単に記憶することができる。さらなる最適化として、ロード時間にデフォルトファイルを素早くカードから読出してキャッシュするように、ベースＣＳＰを構成することができる。
【０１９４】
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
Ｂｕｆｆｅｒ
ＢｕｆｆｅｒＬｅｎｇｔｈ
出力：
Ｓｔａｔｕｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ
目的：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅによって指定された全ファイルを、ユーザ指定バッファに読み出す。上記において、ＬｏｇｉｃａｌＦｉｌｅＮａｍｅによって指定されたロケーションは、完全修飾されたものであり、かつ、ＦｉｌｅＦｏｒｍａｔにより適切に形成されたものであるべきである。
【０１９５】
ＦｉｌｅＣｏｎｔｅｎｔｓパラメータのデータポインタメンバがＮＵＬＬに設定されている場合、その関数は、指定されたファイルのサイズをＦｉｌｅＣｏｎｔｅｎｓｔｓのデータサイズメンバに入れる。ファイルのサイズがＦｉｌｅＣｏｎｔｅｎｔｓのデータサイズメンバよりも大きい場合には、呼出し側のバッファ中にはどのデータもコピーされず、データサイズメンバはそのファイルのサイズに設定される。ファイルのサイズがＦｉｌｅＣｏｎｔｅｎｔｓのデータサイズメンバよりも小さい場合には、そのファイルが呼出し側のバッファ中にコピーされ、データサイズメンバが、そのファイルのサイズに設定される。
【０１９６】
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ
Ｆｉｌｅ Ｃｏｎｔｅｎｔｓ Ｌｅｎｇｔｈ
Ｆｌａｇｓ
出力：
Ｓｔａｔｕｓ
目的：
Ｆｌａｇｓの値に応じて、ファイルが存在しない場合には、そのファイルを作成する。
【０１９７】
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
出力：
Ｓｔａｔｕｓ
目的：
指定されたファイルを削除する。そのファイルが存在しない場合には、返されるステータスは、そのファイルが存在しなかったことを表すはずである。
【０１９８】
ＥｎｕｍＦｉｒｓｔ｜ＥｎｕｍＮｅｘｔ
Ｉｆ ＥｎｕｍＦｉｒｓｔ， ａ ｄｉｒｅｃｔｏｒｙ ｐｒｅｆｉｘ； ｓｅｅ ｂｅｌｏｗ．出力：
ＬｏｇｉｃａｌＦｉｌｅＮａｍｅ
目的：
ＥＮＵＭ＿ＦＩＲＳＴの場合には、ＬｏｇｉｃａｌＦｉｌｅＮａｍｅパラメータは、ディレクトリプレフィックスを含むことができ、それによって列挙の範囲を制限する。
【０１９９】
なし
出力：
Ｓｔａｔｕｓ
カードのスペース情報（例えば、残っているバイト数、利用可能な鍵コンテナの数）
目的：
スマートカードの利用可能な記憶スペースの量を求める。これは場合によっては、概算値のことがある。この情報の使用例として、新しい鍵コンテナを作成できるかどうかを判断する場合、および、所与の証明書に十分なストレージをスマートカードが備えているかどうかを判断する場合が挙げられる。前者では、ＣｒｙｐｔＡｃｑｕｉｒｅＣｏｎｔｅｘｔのＣＲＹＰＴ＿ＮＥＷＫＥＹＳＥＴを呼び出す際に使用することにより、その呼出しが成功したかどうかを、ＣｒｙｐｔＧｅｎＫｅｙが呼び出されるまで鍵自体は作成されなくても、判断することができる。
Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｏｐｅｒａｔｉｏｎｓ
Ｓｉｇｎ Ｄａｔａ ／ Ｐｒｉｖａｔｅ ｋｅｙ Ｄｅｃｒｙｐｔ
【０２００】
暗号機能の残りの機能は、ベースＣＳＰがパフォーマンスのために実行する場合がある。
Ｃｉｐｈｅｒｔｅｘｔ
出力：
Ｓｔａｔｕｓ
Ｐｌａｉｎｔｅｘｔ
目的：
解読するための入力データ（ＲＳＡに基づいたデータ、楕円／超楕円暗号法に基づいたデータなど）を、呼出し側が要求したフォーマット（例えばＰＫＣＳ＃１）に基づいて、ベースＣＳＰがパッドすることができる。したがって、例えばＲＳＡベースのカードの場合、ＣａｒｄＰｒｉｖａｔｅＫｅｙＤｅｃｒｙｐｔに、およびそれから渡されるデータは、常に、公開モジュラスと同じ長さである。これによって、カード特有の層は、様々なパディングスキームを実装しなければならない必要から解放される。ベースＣＳＰは、平文においてパディングを検査することができるため、このＡＰＩは、ハードウェアのエラーの場合を除き、成功するはずである。
【０２０１】
ＡＴ＿ＳＩＧＮＡＴＵＲＥ｜ＡＴ＿ＫＥＹＥＸＣＨＡＮＧＥ
出力：
Ｓｔａｔｕｓ
指定されたアルゴリズムタイプについて、サポートされる鍵サイズ。
目的：
使用されるカードがサポートする公開鍵のサイズを求める。
【０２０２】
データ構造
上記のスマートカード特有の機能のすべてが、共通データ構造を使用することができる。例えば、ＣＡＲＤ＿ＤＡＴＡ構造を定義するために付けられたヘッダを参照されたい。
【０２０３】
実装
カード特有モジュールをプロバイダＤｌｌとして実装することができる。
【０２０４】
上述の方法および装置があれば、スマートカードまたはその他のポータブルデバイスをデータの一般的な記憶にも使用できることがわかるであろう。したがって、スマートカードベンダが、秘密鍵およびそれらに関連付けられた証明書などだけでなく、その他のタイプの資格認定書、特定のアプリケーション、証明書ストアなど、その他の項目に関連するデータの記憶にも使用することができる、汎用スマートカードを提供することを可能にするアーキテクチャが提供される。したがって、上記のモデルをサポートするスマートカードは、おそらく、まだ考慮していない用途においても使用できるであろう。したがって、本明細書で提示している例示的技術は、新たな用途にも適合可能である。
【０２０５】
結論：
本発明の様々な方法および装置のいくつかの例示的実施形態を、添付の図面において例示し、上記の詳細な説明において説明してきたが、本発明は、開示の例示的実施形態に限定されるものではなく、頭記の特許請求の範囲に記載し、それによって定義されている本発明の趣旨から逸脱することなく、多くの再構成、修正、別の形態が可能であることを理解されたい。
【図面の簡単な説明】
【図１】本発明の特定の例示的実施形態で使用するのに適したコンピューティングデバイスを示す構成図である。
【図２】例えば図１に示すようなコンピューティングデバイスで使用するのに適した、ポータブルトークンデバイスのスマートカードとしての実施形態の構成図である。
【図３】スマートカードをコンピューティングデバイスとインタフェースするための、従来のコンピュータソフトウェアアーキテクチャの例示的構成図である。
【図４】本発明の特定の例示的実施形態による、スマートカードおよびその他の同様のデバイスをコンピューティングデバイスにインタフェースするための、改良されたコンピュータソフトウェアアーキテクチャの例示的構成図である。
【符号の説明】
１３０ コンピュータ
１３２ 処理装置（プロセッサ）
１３４ システムメモリ
１３６ バス
１３８ 読出し専用メモリ（ＲＯＭ）
１４０ ランダムアクセスメモリ（ＲＡＭ）
１４２ 基本入出力システム（ＢＩＯＳ）
１４４ ハードディスクドライブ
１４６ 磁気ディスクドライブ
１４８ リムーバブル磁気ディスク（磁気ディスク）
１５０ 光ディスクドライブ
１５２ リムーバブル光ディスク
１５４ ＳＣＳＩインタフェース
１５６ シリアルポートインタフェース（シリアルポート）
１５８ オペレーティングシステム
１６０ アプリケーションプログラム
１６２ その他のプログラムモジュール
１６４ プログラムデータ
１６６ キーボード
１６８ ポインティングデバイス
１７０ インタフェース
１７２ モニタ
１７４ ビデオアダプタ
１７６ リモートコンピュータ
１７８ メモリストレージデバイス
１８０ ローカルエリアネットワーク（ＬＡＮ）
１８２ 広域ネットワーク（ＷＡＮ）
１８４ ネットワークインタフェース（アダプタ）
１８６ モデム
２００ スマートカードリーダ
２０２ スマートカード
２０４ ユニバーサルシリアルバス（ＵＳＢ）ポート（コネクタ）
２０６ ポータブルトークンデバイス（オンボードコントローラまたはプロセッサ）
２０８ オンボードメモリ（メモリ、アクセスメモリ）
３００ ソフトウェアアーキテクチャソリューション
３０２ アプリケーション
３０４ ＣｒｙｐｔｏＡＰＩ
３０６ａ〜ｎ 暗号サービスプロバイダ（ＣＳＰ）
３０８ａ〜ｎ スマートカード（ＳＣ）
４００ ソフトウェアアーキテクチャ
４０４ａ〜ｎ スマートカード特有モジュール
４０２ ベースＣＳＰ
４０６ 管理ＡＰＩ（カード管理ＡＰＩ）
４０８ ＰＩＮマネージャ
４１０ ファイルマネージャ
４１２ コンテナマネージャ
４１４ 暗号マネージャ
Claims (44)
- 暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成可能であり、管理機能グループから選択した少なくとも１つの管理機能を前記暗号提供ロジックに提供するインタフェースロジックを備えた装置であって、
前記管理機能グループは、
識別管理機能と、ファイル管理機能と、コンテナ管理機能と、暗号法管理機能とを含むインタフェースロジックを含むことを特徴とする装置。 - 前記暗号サポートロジックに動作可能に結合されたメモリをさらに含み、前記識別管理機能は、前記メモリ中に記憶されている選択されたデータに基づいて、前記暗号提供ロジックに関連付けてユーザを認証するように構成可能なＰＩＮ管理機能を含むことを特徴とする請求項１に記載の装置。
- 前記暗号サポートロジックに動作可能に結合されたメモリをさらに含み、前記ファイル管理機能は、前記暗号サポートロジックが前記メモリに記憶されている少なくとも１つのデータファイルにアクセスすることを可能にするように構成可能であることを特徴とする請求項１に記載の装置。
- 前記暗号サポートロジックに動作可能に結合されたメモリをさらに含み、前記コンテナ管理機能は、前記暗号サポートロジックが前記メモリに記憶されている少なくとも１つのコンテナオブジェクトにアクセスすることを可能にするように構成可能であることを特徴とする請求項１に記載の装置。
- 前記暗号サポートロジックに動作可能に結合されたメモリをさらに含み、前記暗号法管理機能は、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択した少なくとも１つの暗号機能を実行するように構成可能であり、前記暗号機能は、前記メモリ中に記憶されている鍵データを使用するように動作可能に構成されることを特徴とする請求項１に記載の装置。
- 前記暗号サポートロジックに動作可能に結合されたメモリをさらに含み、前記インタフェースロジックは、前記暗号提供ロジックを修正するように構成可能な少なくとも１つの管理アプリケーションプログラミングインタフェース（ＡＰＩ）をさらに含むことを特徴とする請求項１に記載の装置。
- 前記暗号提供ロジックはポータブルトークン搬送デバイスを含むことを特徴とする請求項１に記載の装置。
- 前記暗号提供ロジックはスマートカードを含むことを特徴とする請求項１に記載の装置。
- 前記暗号提供ロジックはスマートカードリーダデバイスを含むことを特徴とする請求項８に記載の装置。
- 前記暗号サポートロジックは、前記暗号提供ロジックに、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択された少なくとも１つの暗号機能を実施させることによって、アプリケーションの少なくとも１つの出力に応答するように構成可能であることを特徴とする請求項１に記載の装置。
- 前記暗号サポートロジックは暗号アプリケーションプログラミングインタフェース（ＣｒｙｐｔｏＡＰＩ）を含むことを特徴とする請求項１０に記載の装置。
- メモリと、
前記メモリに動作可能に結合されており、前記暗号サポートロジックに関連付けられたコンピュータ実行可能命令と、前記インタフェースロジックに関連付けられたコンピュータ実行可能命令とに従って動作するように構成された少なくとも１つの処理装置と
をさらに含むことを特徴とする請求項１に記載の装置。 - 前記インタフェースロジックはベース暗号サービスプロバイダ（ベースＣＳＰ）を含むことを特徴とする請求項１に記載の装置。
- 前記インタフェースロジックは、少なくとも１つのスマートカードリーダおよび前記ベースＣＳＰにインタフェースを提供するように動作可能に構成できる少なくとも１つのスマートカード特有モジュールをさらに含むことを特徴とする請求項１３に記載の装置。
- 前記ファイル管理機能は、スマートカード上へのデータの選択可能な記憶をサポートするように構成されることを特徴とする請求項１に記載の装置。
- コンピューティングデバイスにおいて使用するのに適したインタフェースロジックを提供するステップであって、前記インタフェースロジックが、暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成可能なステップと、
前記インタフェースロジックを、それが前記暗号提供ロジックに動作可能に結合された場合に、識別確認アクティビティ、ファイルアクセスアクティビティ、コンテナアクセスアクティビティ、および暗号アルゴリズムアクティビティを含むアクティビティグループから選択した、少なくとも１つのアクティビティを実行するように構成するステップと
を含むことを特徴とする方法。 - 前記識別確認アクティビティは、メモリ中に記憶されている選択されたデータに基づいて、エンティティが前記暗号提供ロジックに関連付けられているかどうかを確認するように構成可能なＰＩＮ管理マネージャ機能を含むことを特徴とする請求項１６に記載の方法。
- 前記ファイルアクセス機能は、前記暗号サポートロジックが、前記暗号提供ロジックに動作可能に関連付けられたメモリ中に記憶されている少なくとも１つのデータファイルにアクセスすることを可能にするように構成可能なファイル管理機能を含むことを特徴とする請求項１６に記載の方法。
- 前記コンテナアクセス機能は、前記暗号サポートロジックが、前記暗号提供ロジックに動作可能に関連付けられたメモリ中に記憶されている少なくとも１つのコンテナオブジェクトにアクセスすることを可能にするように構成可能なコンテナ管理機能を含むことを特徴とする請求項１６に記載の方法。
- 前記暗号アルゴリズムアクティビティは、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択した少なくとも１つの暗号機能を実行するように構成可能な暗号法管理機能をさらに含み、前記暗号機能は、前記暗号提供ロジックに動作可能に関連付けられたメモリ中に記憶されている、鍵データを使用するように動作可能に構成されることを特徴とする請求項１６に記載の方法。
- 前記インタフェースロジックは、前記暗号提供ロジックを修正するように構成可能な少なくとも１つの管理アプリケーションプログラミングインタフェース（ＡＰＩ）をさらに含むことを特徴とする請求項１６に記載の方法。
- 前記暗号提供ロジックはポータブルトークン搬送デバイスを含むことを特徴とする請求項１６に記載の方法。
- 前記暗号提供ロジックはスマートカードを含むことを特徴とする請求項１６に記載の方法。
- 前記暗号提供ロジックを少なくとも１つのスマートカードリーダに動作可能に結合することをさらに含むことを特徴とする請求項２３に記載の方法。
- 前記暗号サポートロジックを動作可能に構成して、少なくとも１つのアプリケーションの少なくとも１つの出力に応答するステップと、
前記暗号提供ロジックに、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択した少なくとも１つの暗号機能を実行させるステップとをさらに含むことを特徴とする請求項１６に記載の方法。 - 前記暗号サポートロジックは暗号アプリケーションプログラミングインタフェース（ＣｒｙｐｔｏＡＰＩ）を含むことを特徴とする請求項２５に記載の方法。
- メモリに動作可能に結合された少なくとも１つの処理装置を、前記暗号サポートロジックによって提供されるコンピュータ実行可能命令と、前記インタフェースロジックによって提供されるコンピュータ実行可能命令とに従って動作させるステップをさらに含むことを特徴とする請求項１６に記載の方法。
- 前記インタフェースロジックはベース暗号サービスプロバイダ（ベースＣＳＰ）を含むことを特徴とする請求項１６に記載の方法。
- 前記インタフェースロジックを、少なくとも１つのスマートカードリーダおよび前記ベースＣＳＰにインタフェースを提供するように動作可能に構成することができる少なくとも１つのスマートカード特有モジュールと、動作可能に結合するステップをさらに含むことを特徴とする請求項２８に記載の方法。
- 前記ファイルアクセス機能はスマートカード上へのデータの選択可能な記憶をサポートするように構成されることを特徴とする請求項１に記載の装置。
- 暗号サポートロジックと暗号提供ロジックを動作可能に結合するように構成可能なインタフェースロジックを確立するステップと、
前記インタフェースロジックに、識別サポート機能、ファイルアクセスサポート機能、コンテナアクセスサポート機能、および暗号サポート機能を含むサポート機能グループから選択した少なくとも１つのサポート機能を確立させるステップとを含む動作を実行するためのコンピュータ実行可能命令を含むことを特徴とするコンピュータ可読媒体。 - 前記識別確認サポート機能は、メモリ中に記憶されている選択されたデータに基づいて、エンティティが前記暗号提供ロジックに正しく関連付けられているかどうかを判断する際の援助を行うように構成可能なＰＩＮ管理マネージャサポート機能を含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記ファイルアクセスサポート機能は、前記暗号サポートロジックが、前記暗号提供ロジックに動作可能に関連付けられたメモリ中に記憶されている少なくとも１つのデータファイルにアクセスすることを可能にするように構成可能なファイル管理サポート機能を含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記コンテナアクセスサポート機能は、前記暗号サポートロジックが、前記暗号提供ロジックに動作可能に関連付けられた前記メモリ中に記憶されている少なくとも１つのコンテナオブジェクトにアクセスすることを可能にするように構成可能なコンテナ管理サポート機能を含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記暗号サポート機能は、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択した、少なくとも１つの暗号機能を実行するように構成可能な暗号法管理サポート機能を含み、前記暗号機能は、前記暗号提供ロジックに動作可能に関連付けられた前記メモリ中に記憶されている鍵データを使用するように動作可能に構成されることを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記インタフェースロジックは前記暗号提供ロジックを修正するように構成可能な少なくとも１つの管理アプリケーションプログラミングインタフェース（ＡＰＩ）をさらに含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記暗号提供ロジックはポータブルトークン搬送デバイスを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記暗号提供ロジックは、スマートカードを含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記暗号提供ロジックを少なくとも１つのスマートカードリーダに動作可能に結合するステップを含む、さらなる動作を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項３８に記載のコンピュータ可読媒体。
- 前記暗号サポートロジックを動作可能に構成して、少なくとも１つのアプリケーションの少なくとも１つの出力に応答するステップと、
前記暗号提供ロジックに、認証機能、データ暗号化機能、データ解読機能、メッセージダイジェスト機能、署名機能、およびハッシュ機能を含む暗号機能グループから選択した少なくとも１つの暗号機能を実行させるステップとを含む、さらなる動作を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項３１に記載のコンピュータ可読媒体。 - 前記暗号サポートロジックは暗号アプリケーションプログラミングインタフェース（ＣｒｙｐｔｏＡＰＩ）を含むことを特徴とする請求項４０に記載のコンピュータ可読媒体。
- 前記インタフェースロジックはベース暗号サービスプロバイダ（ベースＣＳＰ）を含むことを特徴とする請求項３１に記載のコンピュータ可読媒体。
- 前記インタフェースロジックを、少なくとも１つのスマートカードリーダおよび前記ベースＣＳＰにインタフェースを提供するように動作可能に構成することができる少なくとも１つのスマートカード特有モジュールと動作可能に結合するステップを含む、さらなる動作を実行するためのコンピュータ実行可能命令を有することを特徴とする請求項４２に記載のコンピュータ可読媒体。
- 前記ファイルアクセスサポート機能はスマートカード上へのデータの選択可能な記憶をサポートするように構成されることを特徴とする請求項１に記載の装置。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/179,655 US7200756B2 (en) | 2002-06-25 | 2002-06-25 | Base cryptographic service provider (CSP) methods and apparatuses |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004048742A true JP2004048742A (ja) | 2004-02-12 |
| JP2004048742A5 JP2004048742A5 (ja) | 2006-08-10 |
| JP4564243B2 JP4564243B2 (ja) | 2010-10-20 |
Family
ID=29717910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003180213A Expired - Fee Related JP4564243B2 (ja) | 2002-06-25 | 2003-06-24 | ベース暗号サービスプロバイダ（ｃｓｐ）の方法および装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7200756B2 (ja) |
| EP (1) | EP1376300A3 (ja) |
| JP (1) | JP4564243B2 (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008517400A (ja) * | 2004-10-20 | 2008-05-22 | インテル・コーポレーション | データセキュリティ |
| JP2010503301A (ja) * | 2006-09-07 | 2010-01-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 暗号化マネージャ及び鍵マネージャと通信するようにストレージ・ドライブを構成する方法 |
| JP2010517424A (ja) * | 2007-01-26 | 2010-05-20 | マイクロソフト コーポレーション | Ｕｓｂトークン上の暗号化キーコンテナ |
| JP2018170802A (ja) * | 2013-06-20 | 2018-11-01 | アマゾン テクノロジーズ インコーポレイテッド | 複数許可データセキュリティ及びアクセス |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7334130B2 (en) * | 2002-07-19 | 2008-02-19 | Bowers Charles R | Method and apparatus for managing confidential information |
| US9218507B2 (en) * | 2002-07-19 | 2015-12-22 | Charles R. Bowers | Method and apparatus for managing confidential information |
| AU2003265034A1 (en) * | 2002-10-07 | 2004-04-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Security and privacy enhancements for security devices |
| JP3738761B2 (ja) * | 2003-01-16 | 2006-01-25 | コニカミノルタビジネステクノロジーズ株式会社 | 複合型画像処理装置 |
| US8010670B2 (en) | 2003-12-23 | 2011-08-30 | Slipstream Data Inc. | Meta-data based method for local cache utilization |
| US20050182934A1 (en) * | 2004-01-28 | 2005-08-18 | Laszlo Elteto | Method and apparatus for providing secure communications between a computer and a smart card chip |
| US7865716B2 (en) * | 2004-03-15 | 2011-01-04 | Panasonic Corporation | Encryption device, key distribution device and key distribution system |
| EP1745590A4 (en) * | 2004-04-22 | 2008-11-26 | Fortress Gb Ltd | CERTIFIED USER PROFILES, ABSTRACTS AND ANONYMOUS FOR RESTRICTED ACCESS TO A NETWORK SITE AND STATISTICAL SOCIAL SURVEYS |
| JP4781033B2 (ja) * | 2004-08-10 | 2011-09-28 | キヤノン株式会社 | 認証システム、処理方法、プログラム及び記録媒体 |
| US20060075254A1 (en) * | 2004-09-27 | 2006-04-06 | Cisco Technology, Inc. (A California Corporation) | Smart card functionality from a security co-processor and symmetric key in ROM |
| US7958369B2 (en) * | 2004-10-22 | 2011-06-07 | Hewlett-Packard Development Company, L.P. | Systems and methods for multiple level control of access of privileges to protected media content |
| US20080288786A1 (en) * | 2004-12-20 | 2008-11-20 | Michael Stephen Fiske | System with access keys |
| US7831051B2 (en) * | 2007-03-13 | 2010-11-09 | Aladdin Europe Gmbh | Secure communication between a hardware device and a computer |
| CN101884188A (zh) | 2007-07-12 | 2010-11-10 | 创新投资有限责任公司 | 身份鉴别和受保护访问系统、组件和方法 |
| JP5209281B2 (ja) * | 2007-11-22 | 2013-06-12 | 株式会社エヌ・ティ・ティ・ドコモ | 通信端末装置、アクセス制御方法、ｉｃカード |
| US8281145B2 (en) * | 2007-12-14 | 2012-10-02 | Mehran Randall Rasti | Doing business without SSN, EIN, and charge card numbers |
| US20090276837A1 (en) * | 2008-04-30 | 2009-11-05 | Microsoft Corporation | Credential equivalency and control |
| JP5319238B2 (ja) * | 2008-10-29 | 2013-10-16 | 真二 栗本 | 情報処理システム、情報処理装置、情報処理方法、および情報処理プログラム |
| US8930655B2 (en) | 2009-01-19 | 2015-01-06 | Microsoft Corporation | Transient storage device configuration silo |
| US20100185843A1 (en) * | 2009-01-20 | 2010-07-22 | Microsoft Corporation | Hardware encrypting storage device with physically separable key storage device |
| US8788831B2 (en) * | 2009-03-20 | 2014-07-22 | Barracuda Networks, Inc. | More elegant exastore apparatus and method of operation |
| US9330282B2 (en) * | 2009-06-10 | 2016-05-03 | Microsoft Technology Licensing, Llc | Instruction cards for storage devices |
| US8321956B2 (en) | 2009-06-17 | 2012-11-27 | Microsoft Corporation | Remote access control of storage devices |
| US9396464B2 (en) * | 2010-09-14 | 2016-07-19 | Ncr Corporation | Updating multi-media content in a digital download kiosk |
| US9251337B2 (en) * | 2011-04-27 | 2016-02-02 | International Business Machines Corporation | Scalable, highly available, dynamically reconfigurable cryptographic provider with quality-of-service control built from commodity backend providers |
| DE102012104228B4 (de) * | 2012-05-15 | 2020-12-10 | Fujitsu Technology Solutions Intellectual Property Gmbh | Elektronisches Zugangsschutzsystem, Verfahren zum Betrieb eines Computersystems, Chipkarte und Firmwarekomponente |
| CN102752104B (zh) * | 2012-06-07 | 2017-10-31 | 中国电子科技集团公司第三十研究所 | 一种基于智能卡cos的对称密码服务实现方法 |
| US10362006B2 (en) | 2013-03-15 | 2019-07-23 | Mastercard International Incorporated | Systems and methods for cryptographic security as a service |
| US9317718B1 (en) | 2013-03-29 | 2016-04-19 | Secturion Systems, Inc. | Security device with programmable systolic-matrix cryptographic module and programmable input/output interface |
| US9798899B1 (en) | 2013-03-29 | 2017-10-24 | Secturion Systems, Inc. | Replaceable or removable physical interface input/output module |
| US9355279B1 (en) | 2013-03-29 | 2016-05-31 | Secturion Systems, Inc. | Multi-tenancy architecture |
| US9374344B1 (en) * | 2013-03-29 | 2016-06-21 | Secturion Systems, Inc. | Secure end-to-end communication system |
| US9524399B1 (en) * | 2013-04-01 | 2016-12-20 | Secturion Systems, Inc. | Multi-level independent security architecture |
| CA2952621A1 (en) * | 2014-06-18 | 2015-12-23 | James Collier | Methods and apparatus for cryptography |
| CN104679513B (zh) * | 2015-02-12 | 2019-09-27 | 无锡识凌科技有限公司 | 一种智能终端中的设备驱动架构开发方法 |
| US10237246B1 (en) | 2015-07-31 | 2019-03-19 | Symphony Communication Services Holdings Llc | Secure message search |
| US9794064B2 (en) | 2015-09-17 | 2017-10-17 | Secturion Systems, Inc. | Client(s) to cloud or remote server secure data or file object encryption gateway |
| US11283774B2 (en) | 2015-09-17 | 2022-03-22 | Secturion Systems, Inc. | Cloud storage using encryption gateway with certificate authority identification |
| US10708236B2 (en) | 2015-10-26 | 2020-07-07 | Secturion Systems, Inc. | Multi-independent level secure (MILS) storage encryption |
| US9613221B1 (en) * | 2015-12-30 | 2017-04-04 | Quixey, Inc. | Signed application cards |
| US10819709B1 (en) * | 2016-09-26 | 2020-10-27 | Symphony Communication Services Holdings Llc | Authorizing delegated capabilities to applications in a secure end-to-end communications system |
| US10476870B2 (en) * | 2017-08-25 | 2019-11-12 | Microsoft Technology Licensing, Llc | Local claim-based security service with cross-browser compatibility |
| JP7178500B2 (ja) * | 2019-07-23 | 2022-11-25 | 株式会社ソニー・インタラクティブエンタテインメント | アクセス制御装置、アクセス制御方法及びプログラム |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0936851A (ja) * | 1995-07-07 | 1997-02-07 | Sun Microsyst Inc | スマート・カードからのプライベート鍵操作をホスト・ベースの暗号サービスと透過的に統合するシステム及び方法 |
| JP2002108210A (ja) * | 2000-09-28 | 2002-04-10 | Hitachi Software Eng Co Ltd | 依頼計算方法 |
| US20040223607A1 (en) * | 2001-06-07 | 2004-11-11 | Griffin Daniel C. | Tester of cryptographic service providers |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
| US6038551A (en) * | 1996-03-11 | 2000-03-14 | Microsoft Corporation | System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer |
| US5933503A (en) * | 1996-03-15 | 1999-08-03 | Novell, Inc | Controlled modular cryptography apparatus and method |
| DE19838628A1 (de) | 1998-08-26 | 2000-03-02 | Ibm | Erweiterte Chipkarten-Kommunikationsarchitektur und Verfahren zur Kommunikation zwischen Chipkartenanwendung und Datenträger |
| US6360952B1 (en) * | 1998-05-29 | 2002-03-26 | Digital Privacy, Inc. | Card access system supporting multiple cards and card readers |
| EP1125262A1 (en) * | 1998-10-27 | 2001-08-22 | Visa International Service Association | Delegated management of smart card applications |
| US6651168B1 (en) * | 1999-01-29 | 2003-11-18 | International Business Machines, Corp. | Authentication framework for multiple authentication processes and mechanisms |
| US6484259B1 (en) | 1999-07-23 | 2002-11-19 | Microsoft Corporation | Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment |
| US7085931B1 (en) | 1999-09-03 | 2006-08-01 | Secure Computing Corporation | Virtual smart card system and method |
| US6792536B1 (en) * | 1999-10-20 | 2004-09-14 | Timecertain Llc | Smart card system and methods for proving dates in digital files |
| US6427911B1 (en) * | 1999-12-17 | 2002-08-06 | International Business Machines Corporation | Billing/clearing house system and method for an overloaded card |
| US20020120842A1 (en) | 2000-11-29 | 2002-08-29 | Helge Bragstad | Method, apparatus and computer program product for interoperable cryptographic material |
| JP3880384B2 (ja) * | 2001-12-06 | 2007-02-14 | 松下電器産業株式会社 | Ｉｃカード |
| US20030154375A1 (en) * | 2002-02-08 | 2003-08-14 | Weimin Yang | Universal crypto-adaptor system for supporting multiple APIs and multiple smart cards |
-
2002
- 2002-06-25 US US10/179,655 patent/US7200756B2/en not_active Expired - Fee Related
-
2003
- 2003-05-12 EP EP03010613A patent/EP1376300A3/en not_active Ceased
- 2003-06-24 JP JP2003180213A patent/JP4564243B2/ja not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0936851A (ja) * | 1995-07-07 | 1997-02-07 | Sun Microsyst Inc | スマート・カードからのプライベート鍵操作をホスト・ベースの暗号サービスと透過的に統合するシステム及び方法 |
| JP2002108210A (ja) * | 2000-09-28 | 2002-04-10 | Hitachi Software Eng Co Ltd | 依頼計算方法 |
| US20040223607A1 (en) * | 2001-06-07 | 2004-11-11 | Griffin Daniel C. | Tester of cryptographic service providers |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008517400A (ja) * | 2004-10-20 | 2008-05-22 | インテル・コーポレーション | データセキュリティ |
| US9135470B2 (en) | 2004-10-20 | 2015-09-15 | Intel Corporation | Data security |
| US9654464B2 (en) | 2004-10-20 | 2017-05-16 | Intel Corporation | Data security |
| JP2010503301A (ja) * | 2006-09-07 | 2010-01-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 暗号化マネージャ及び鍵マネージャと通信するようにストレージ・ドライブを構成する方法 |
| JP2010517424A (ja) * | 2007-01-26 | 2010-05-20 | マイクロソフト コーポレーション | Ｕｓｂトークン上の暗号化キーコンテナ |
| US8588421B2 (en) | 2007-01-26 | 2013-11-19 | Microsoft Corporation | Cryptographic key containers on a USB token |
| JP2018170802A (ja) * | 2013-06-20 | 2018-11-01 | アマゾン テクノロジーズ インコーポレイテッド | 複数許可データセキュリティ及びアクセス |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4564243B2 (ja) | 2010-10-20 |
| EP1376300A3 (en) | 2005-08-31 |
| EP1376300A2 (en) | 2004-01-02 |
| US7200756B2 (en) | 2007-04-03 |
| US20030236987A1 (en) | 2003-12-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4564243B2 (ja) | ベース暗号サービスプロバイダ（ｃｓｐ）の方法および装置 | |
| US6484259B1 (en) | Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment | |
| US8549313B2 (en) | Method and system for integrated securing and managing of virtual machines and virtual appliances | |
| JP4841563B2 (ja) | 暗号機能を実行するためのデータ処理システム、方法、およびコンピュータ・プログラム | |
| Kinney | Trusted platform module basics: using TPM in embedded systems | |
| US7568114B1 (en) | Secure transaction processor | |
| US8645717B2 (en) | System and method for securely storing firmware | |
| JP4550147B2 (ja) | コンポーネントをロードするための方法、システム及び記録媒体 | |
| US6272631B1 (en) | Protected storage of core data secrets | |
| US7434263B2 (en) | System and method for secure storage data using a key | |
| US7805375B2 (en) | Digital license migration from first platform to second platform | |
| US8112628B2 (en) | Using a portable computing device as a smart key device | |
| US6839437B1 (en) | Method and apparatus for managing keys for cryptographic operations | |
| US20060174352A1 (en) | Method and apparatus for providing versatile services on storage devices | |
| US6986041B2 (en) | System and method for remote code integrity in distributed systems | |
| JP2013514587A (ja) | 証明書失効リストを用いたコンテンツ管理方法 | |
| US20050154898A1 (en) | Method and system for protecting master secrets using smart key devices | |
| US20020166051A1 (en) | Method, system, and apparatus for encrypting a web browser script | |
| Wang | Towards a General Purpose Trusted Computing Platform for All Vendors and Applications | |
| EP1505473A1 (en) | Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment | |
| Liu | CSFS: a secure file system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060623 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060623 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091016 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100113 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100723 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100730 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130806 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |