スマート カードのアーキテクチャ

• 適用対象:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

IT プロフェッショナル向けのこのトピックでは、資格情報プロバイダー アーキテクチャやスマート カード サブシステム アーキテクチャなど、Windows オペレーティング システムでスマート カードをサポートするシステム アーキテクチャについて説明します。

認証は、オブジェクトまたはユーザーの ID を検証するためのプロセスです。 スマート カードなどのオブジェクトを認証する場合、目的はオブジェクトが正規であることを確認することです。 ユーザーを認証する際の目標は、詐欺師を扱っていないかどうかを確認することです。

ネットワーク コンテキストでは、認証はネットワーク アプリケーションまたはリソースに ID を証明する行為です。 通常、ID は、ユーザーだけが認識するキー (公開キー暗号化など) または共有キーを使用する暗号化操作によって証明されます。 認証交換のサーバー側では、署名されたデータと既知の暗号化キーが比較され、認証試行が検証されます。 暗号化キーをセキュリティで保護された中央の場所に格納すると、認証プロセスはスケーラブルで保守可能になります。

スマート カードの場合、Windows では、セキュリティで保護された認証要件を満たし、カスタム資格情報プロバイダーを含めることができるように拡張可能なプロバイダー アーキテクチャがサポートされています。 このトピックには、次に関する情報が含まれています。

• 資格情報プロバイダーのアーキテクチャ
• スマート カード サブシステム アーキテクチャ

資格情報プロバイダーのアーキテクチャ

次の表に、対話型サインイン アーキテクチャに含まれるコンポーネントの一覧を示します。

コンポーネント	説明
Winlogon	対話型サインイン インフラストラクチャを提供します。
ログオン UI	対話型 UI レンダリングを提供します。
資格情報プロバイダー (パスワードとスマート カード)	資格情報情報と資格情報のシリアル化について説明します。
ローカル セキュリティ機関 (LSA)	サインイン資格情報を処理します。
認証パッケージ	NTLM と Kerberos プロトコルが含まれます。 サーバー認証パッケージと通信してユーザーを認証します。

ユーザーが Ctrl キーを押しながら Alt キーを押しながら DEL キーを押すと、対話型サインイン Windows が開始されます。 Ctrl + ALT + DEL キーの組み合わせは、セキュア アテンション シーケンス (SAS) と呼ばれます。 他のプログラムやプロセスでの使用を防ぐために、Winlogon はブート プロセス中にこのシーケンスを登録します。

SAS を受信すると、UI によって、登録された資格情報プロバイダーから受信した情報からサインイン タイルが生成されます。 次の図は、Windows オペレーティング システムの資格情報プロバイダーのアーキテクチャを示しています。

通常、ローカル アカウントまたはドメイン アカウントを使用してコンピューターにサインインするユーザーは、ユーザー名とパスワードを入力する必要があります。 これらの資格情報は、ユーザーの ID を確認するために使用されます。 スマート カード サインインの場合、ユーザーの資格情報はスマート カードのセキュリティ チップに含まれます。 スマート カード リーダーを使用すると、コンピューターはスマート カード上のセキュリティ チップと対話できます。 ユーザーがスマート カードでサインインすると、ユーザー名とパスワードの代わりに個人識別番号 (PIN) を入力します。

資格情報プロバイダーは、ローカル システムで実行されるインプロセス COM オブジェクトであり、資格情報の収集に使用されます。 ログオン UI は対話型 UI レンダリングを提供し、Winlogon は対話型サインイン インフラストラクチャを提供し、資格情報プロバイダーはこれらの両方のコンポーネントと連携して資格情報の収集と処理に役立ちます。

Winlogon は、SAS イベントを受信した後に資格情報プロバイダー タイルを表示するようにログオン UI に指示します。 ログオン UI は、列挙する資格情報の数を各資格情報プロバイダーに照会します。 資格情報プロバイダーには、これらのタイルのいずれかを既定として指定するオプションがあります。 すべてのプロバイダーがタイルを列挙すると、ログオン UI によってユーザーに表示されます。 ユーザーはタイルと対話して、適切な資格情報を指定します。 ログオン UI は、認証のためにこれらの資格情報を送信します。

サポートハードウェアと組み合わせることで、資格情報プロバイダーは Windows オペレーティング システムを拡張して、ユーザーが生体認証 (指紋、網膜、音声認識など)、パスワード、PIN、スマート カード証明書、またはカスタム認証パッケージを使用してサインインできるようにします。 企業と IT プロフェッショナルは、すべてのドメイン ユーザーに対してカスタム認証メカニズムを開発および展開できます。また、ユーザーにこのカスタム サインイン メカニズムの使用を明示的に要求する場合があります。

注

資格情報プロバイダーは強制メカニズムではありません。 これらは、資格情報の収集とシリアル化に使用されます。 LSA と認証パッケージはセキュリティを適用します。

資格情報プロバイダーは、シングル サインイン (SSO) をサポートするように設計できます。 このプロセスでは、コンピューターにサインインするために (RADIUS やその他のテクノロジを使用して) セキュリティで保護されたネットワーク アクセス ポイントに対してユーザーを認証します。 資格情報プロバイダーは、アプリケーション固有の資格情報の収集をサポートするようにも設計されており、ネットワーク リソースへの認証、コンピューターのドメインへの参加、またはユーザー アカウント制御 (UAC) の管理者の同意に使用できます。

1 つのコンピューターで複数の資格情報プロバイダーを共存させることができます。

資格情報プロバイダーは、Windows を実行しているコンピューターに登録する必要があり、次の責任を負います。

• 認証に必要な資格情報の記述
• 外部認証機関との通信とロジックの処理
• 対話型サインインとネットワーク サインインの資格情報のパッケージ化

注

資格情報プロバイダー API は UI をレンダリングしません。 レンダリングする必要がある内容について説明します。
パスワード資格情報プロバイダーのみがセーフ モードで使用できます。
スマート カード資格情報プロバイダーは、ネットワーク中にセーフ モードで使用できます。

スマート カード サブシステム アーキテクチャ

ベンダーはスマート カードとスマート カード リーダーを提供し、多くの場合、スマート カードとスマート カード リーダーではベンダーが異なります。 スマート カード リーダーのドライバーは、パーソナル コンピューター/スマート カード (PC/SC) 標準に書き込まれます。 各スマート カードには、暗号化操作を有効にするために CryptoAPI インターフェイスを使用する暗号化サービス プロバイダー (CSP) と、スマート カード ハードウェアとの通信を有効にする WinSCard API が必要です。

基本 CSP とスマート カード ミニドライバー アーキテクチャ

次の図は、CryptoAPI、CSP、スマート カード ベース暗号化サービス プロバイダー (Base CSP)、スマート カード ミニドライバーの関係を示しています。

ベース CSP とスマート カード KSP を使用したキャッシュ

スマート カード アーキテクチャでは、キャッシュ メカニズムを使用して操作を合理化し、PIN へのユーザーのアクセスを向上させます。

• データ キャッシュ: データ キャッシュは、スマート カード I/O 操作を最小限に抑えるための 1 つのプロセスを提供します
• PIN キャッシュ: PIN キャッシュは、スマート カードが認証されていないたびに PIN を再入力する必要がないというユーザーを支援します

データ キャッシュ

各 CSP は、現在のスマート カード データ キャッシュを個別に実装します。 Base CSP では、1 つのプロセスでスマート カード I/O 操作を最小限に抑える堅牢なキャッシュ メカニズムが実装されています。

既存のグローバル キャッシュは次のように機能します。

1. アプリケーションは暗号化操作を要求します。 たとえば、ユーザー証明書はスマート カードから読み取られます
2. CSP は、そのキャッシュでアイテムをチェックします
3. アイテムがキャッシュに見つからない場合、またはアイテムがキャッシュされているが最新ではない場合、アイテムはスマート カードから読み取られます。
4. スマート カードから読み取られた項目がキャッシュに追加されます。 その項目の既存の古いコピーが置き換えられます

CSP では、3 種類のオブジェクトまたはデータがキャッシュされます。ピン (詳細については、「 PIN キャッシュ」を参照)、証明書、およびファイルを参照してください。 キャッシュされたデータのいずれかが変更された場合、対応するオブジェクトは、後続の操作でスマート カードから読み取られます。 たとえば、ファイルがスマート カードに書き込まれた場合、CSP キャッシュはファイルの古いものになり、他のプロセスはスマート カードを少なくとも 1 回読み取って CSP キャッシュを更新します。

グローバル データ キャッシュは、Windows 用スマート カード サービスでホストされます。 Windows には、SCardWriteCache と SCardReadCache という 2 つのパブリック スマート カード API 呼び出しが含まれています。 これらの API 呼び出しにより、グローバル データ キャッシュ機能をアプリケーションで使用できるようになります。 スマート カード ミニドライバーの仕様に準拠するすべてのスマート カードには、16 バイトのカード識別子があります。 この値は、特定のスマート カードに関連するキャッシュされたデータを一意に識別するために使用されます。 標準の Windows GUID の種類が使用されます。 これらの API を使用すると、アプリケーションはグローバル キャッシュにデータを追加し、データを読み取られます。

PIN キャッシュ

PIN キャッシュは、スマート カードが認証されていないたびに、ユーザーが PIN を入力しないように保護します。 スマート カードが認証されると、ホスト側アプリケーション間で区別されず、どのアプリケーションでもスマート カード上のプライベート データにアクセスできます。

これを軽減するために、スマート カードは、アプリケーションがスマート カードに対して認証されるときに排他的状態になります。 ただし、これは、他のアプリケーションがスマート カードと通信できないため、ブロックされることを意味します。 そのため、このような排他接続は最小限に抑えられます。 問題は、プロトコル (Kerberos プロトコルなど) が複数の署名操作を必要とすることです。 そのため、プロトコルは、長期間にわたってスマート カードへの排他的アクセスを必要とするか、複数の認証操作を必要とします。 ここでは、PIN キャッシュを使用して、ユーザーに PIN を複数回入力することなく、スマート カードの排他的な使用を最小限に抑えます。

次の例は、このしくみを示しています。 このシナリオには、Outlook とインターネット エクスプローラーの 2 つのアプリケーションがあります。 アプリケーションは、さまざまな目的でスマート カードを使用します。

1. ユーザーは Outlook を起動し、署名された電子メールの送信を試みます。 秘密キーはスマート カード上にある
2. Outlook では、ユーザーにスマート カード PIN の入力を求めるメッセージが表示されます。 ユーザーが正しい PIN を入力する
3. 電子メール データは、署名操作のスマート カードに送信されます。 Outlook クライアントは応答の書式を設定し、電子メールを送信します
4. ユーザーはインターネット エクスプローラーを開き、クライアントのトランスポート層セキュリティ (TLS) 認証を必要とする保護されたサイトにアクセスしようとします
5. インターネット エクスプローラーは、スマート カード PIN の入力をユーザーに求めます。 ユーザーが正しい PIN を入力する
6. TLS 関連の秘密キー操作はスマート カードで行われ、ユーザーは認証され、サインインされます
7. ユーザーは Outlook に戻り、別の署名済み電子メールを送信します。 今回は、PIN が前の操作からキャッシュされているため、ユーザーは PIN の入力を求められません。 同様に、ユーザーがインターネット エクスプローラーをもう一度使用して別の操作を行った場合、インターネット エクスプローラーはユーザーに PIN の入力を求められません

Base CSP は、PIN のプロセスごとのキャッシュを内部的に保持します。 PIN は暗号化され、メモリに格納されます。 PIN のセキュリティ保護に使用される関数は RtlEncryptMemory、RtlDecryptMemory、RtlSecureZeroMemory であり、PIN を含む空のバッファーになります。

スマート カードの選択

この記事の次のセクションでは、Windows がスマート カード アーキテクチャを使用して、スマート カード サインインを成功させるために正しいスマート カード リーダー ソフトウェア、プロバイダー、資格情報を選択する方法について説明します。

• コンテナー仕様レベル
• コンテナー操作
• コンテキスト フラグ
• サイレント コンテキストで新しいコンテナーを作成する
• スマート カード選択動作
• スマート カード リーダーを一致させる
• スマート カードマッチを作成する
• 既存の既定のコンテナーを開く (リーダーが指定されていない)
• 既存の GUID 名付きコンテナーを開く (リーダーが指定されていない)
• 新しいコンテナーを作成する (リーダーが指定されていない)
• コンテナーを削除する

コンテナー仕様レベル

CryptoAPI の CryptAcquireContext 呼び出しに応答して、Base CSP は、呼び出し元が指定するコンテナーを特定のスマート カードとリーダーと照合しようとします。 呼び出し元は、次の表に示すように、さまざまなレベルの特異性を持つコンテナー名を指定し、最も固有の要求から最も固有の要求に並べ替えることができます。

同様に、CNG の NCryptOpenKey 呼び出しに応答して、スマート カード KSP は同じ方法でコンテナーの照合を試み、次の表に示すように同じコンテナー形式を受け取ります。

注

スマート カード KSP を使用してキーを開く前に、NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER) を呼び出す必要があります。

Type	名前	Format
私	リーダー名とコンテナー名	\.<Reader Name><Container Name>
Ii	リーダー名とコンテナー名 (NULL)	\.<Reader Name>
Iii	コンテナー名のみ	<Container Name>
IV	既定のコンテナー (NULL) のみ	Null

Base CSP とスマート カード KSP キャッシュ スマート カードは、呼び出し元プロセスに関する情報と、プロセスがアクセスしたスマート カードに関する情報を処理します。 スマート カード コンテナーを検索する場合、Base CSP またはスマート カード KSP は、最初にキャッシュでプロセスを確認します。 キャッシュされたハンドルが無効な場合、または一致するものが見つからない場合は、カード ハンドルを取得するために SCardUIDlg API が呼び出されます。

コンテナー操作

CryptAcquireContext を使用して、次の 3 つのコンテナー操作を要求できます。

1. 新しいコンテナーを作成します。 (dwFlags が CRYPT_NEWKEYSET に設定されている CryptAcquireContext と同等の CNG は NCryptCreatePersistedKey です)。
2. 既存のコンテナーを開きます。 (コンテナーを開く CNG と同等の CryptAcquireContext は NCryptOpenKey です)。
3. コンテナーを削除します。 (dwFlags が CRYPT_DELETEKEYSET に設定されている CryptAcquireContext と同等の CNG は NCryptDeleteKey です)。

暗号化ハンドルを特定のスマート カードとリーダーに関連付けるために使用されるヒューリスティックは、要求されたコンテナー操作と使用されるコンテナー仕様のレベルに基づいています。

次の表は、コンテナー作成操作の制限を示しています。

仕様	制限
サイレント コンテキストなし	キー コンテナーの作成では、常に PIN プロンプトなどの UI を表示できる必要があります。
既存のコンテナーを上書きしない	選択したスマート カードに指定したコンテナーが既に存在する場合は、別のスマート カードを選択するか、操作を取り消します。

コンテキスト フラグ

次の表は、コンテナー作成操作の制限として使用されるコンテキスト フラグを示しています。

Flag	説明
CRYPT_SILENT	この操作中に UI を表示することはできません。
CRYPT_MACHINE_KEYSET	この操作では、キャッシュされたデータを使用しないでください。
CRYPT_VERIFYCONTEXT	スマート カードではパブリック データにのみアクセスできます。

コンテナーの操作とコンテナーの仕様に加えて、スマート カードの選択中に、CryptAcquireContext フラグなどの他のユーザー オプションを検討する必要があります。

重要

CRYPT_SILENT フラグを使用して新しいコンテナーを作成することはできません。

サイレント コンテキストで新しいコンテナーを作成する

アプリケーションは、 で Base CSP を CRYPT_DEFAULT_CONTAINER_OPTIONAL呼び出し、サイレント コンテキストで PIN を設定し、サイレント コンテキストで新しいコンテナーを作成できます。 この操作は次のように実行されます。

1. スマート カード リーダー名をタイプ II コンテナー仕様レベルとして渡し、フラグを指定して CryptAcquireContext をCRYPT_DEFAULT_CONTAINER_OPTIONAL呼び出します。
2. または PP_SIGNATURE_PIN を指定して CryptSetProvParam を呼び出し、null で終わる ASCII PIN を指定PP_KEYEXCHANGE_PINします。
3. 手順 1 で取得したコンテキストを解放する
4. で CryptAcquireContext を CRYPT_NEWKEYSET呼び出し、I 型コンテナー仕様レベルを指定します
5. CryptGenKey を呼び出してキーを作成する

スマート カード選択動作

次のいくつかのシナリオでは、ユーザーにスマート カードの挿入を求めることができます。 ユーザー コンテキストがサイレントの場合、この操作は失敗し、UI は表示されません。 それ以外の場合、UI に応答して、ユーザーはスマート カードを挿入するか、[キャンセル] を選択できます。 ユーザーが操作を取り消すと、操作は失敗します。 フローチャートは、Windows オペレーティング システムによって実行される選択手順を示しています。

一般に、スマート カード選択動作は SCardUIDlgSelectCard API によって処理されます。 Base CSP は、この API を直接呼び出すことによって、この API と対話します。 Base CSP は、候補のスマート カードをフィルター処理して照合する目的を持つコールバック関数も送信します。 CryptAcquireContext の呼び出し元は、スマート カード一致する情報を提供します。 内部的には、Base CSP はスマート カードシリアル番号、リーダー名、コンテナー名の組み合わせを使用して、特定のスマート カードを検索します。

をSCardUI *呼び出すたびに、候補のスマート カードから追加情報が読み取られます。 Base CSP スマート カード選択コールバックは、この情報をキャッシュします。

スマート カード リーダーを一致させる

タイプ I およびタイプ II のコンテナー仕様レベルの場合、スマート カード選択プロセスは、名前付きリーダー内のスマート カードのみが一致と見なすことができるため、あまり複雑ではありません。 スマート カードとスマート カード リーダーを照合するプロセスは次のとおりです。

1. 要求されたスマート カード リーダーを見つけます。 見つからない場合、プロセスは失敗します (これにはリーダー名によるキャッシュ検索が必要です)
2. リーダーにスマート カードがない場合、ユーザーはスマート カードを挿入するように求められます。 (これは非執拗モードのみです。呼び出しがサイレント モードの場合は失敗します)
3. コンテナー仕様レベル II の場合のみ、選択したスマート カードの既定のコンテナーの名前が決定されます
4. 既存のコンテナーを開くか、既存のコンテナーを削除するには、指定したコンテナーを見つけます。 このスマート カードで指定したコンテナーが見つからない場合、ユーザーはスマート カードを挿入するように求められます。
5. システムが新しいコンテナーを作成しようとすると、指定されたコンテナーがこのスマート カードに既に存在する場合、プロセスは失敗します

スマート カードマッチを作成する

コンテナー仕様レベル III および IV の場合、複数のキャッシュされたスマート カードが指定された条件を満たす可能性があるため、適切なスマート カードをユーザー コンテキストと一致させるために、より広範な方法が使用されます。

既存の既定のコンテナーを開く (リーダーが指定されていない)

注

この操作では、Base CSP でスマート カードを使用する必要があります。

1. Base CSP によってアクセスされ、ハンドルとコンテナーの情報がキャッシュされるスマート カードごとに、Base CSP は有効な既定のコンテナーを検索します。 キャッシュされた SCARDHANDLE に対して、その有効性を確認する操作が試行されます。 スマート カード ハンドルが有効でない場合、Base CSP は引き続き新しいスマート カードを検索します。
2. 一致するスマート カードが Base CSP キャッシュに見つからない場合、Base CSP はスマート カード サブシステムを呼び出します。 SCardUIDlgSelectCard() は、適切なコールバック フィルターと共に使用され、有効な既定のコンテナーと一致するスマート カードを検索します

既存の GUID 名付きコンテナーを開く (リーダーが指定されていない)

注

この操作では、Base CSP でスマート カードを使用する必要があります。

1. Base CSP に既に登録されているスマート カードごとに、要求されたコンテナーを検索します。 キャッシュされた SCARDHANDLE に対して操作を試み、その有効性を確認します。 スマート カード ハンドルが有効でない場合、スマート カードのシリアル番号が API にSCardUI *渡され、この特定のスマート カードの検索が続行されます (コンテナー名の一般的な一致のみではなく)
2. 一致するスマート カードがベース CSP キャッシュに見つからない場合は、スマート カード サブシステムへの呼び出しが行われます。 SCardUIDlgSelectCard()は、要求されたコンテナーと一致するスマート カードを検索するために、適切なコールバック フィルターと共に使用されます。 または、手順 1 の検索の結果としてスマート カードシリアル番号が発生した場合、コールバック フィルターは、コンテナー名ではなくシリアル番号の照合を試みます

新しいコンテナーを作成する (リーダーが指定されていない)

注

この操作では、Base CSP でスマート カードを使用する必要があります。

PIN がキャッシュされていない場合、ユーザーは少なくとも PIN の入力を求める必要があるため、コンテナーの作成にCRYPT_SILENTは許可されません。

その他の操作の場合、呼び出し元は既定のコンテナーCRYPT_DEFAULT_CONTAINER_OPTIONALに対して検証コンテキストを取得し、CryptSetProvParam を使用して呼び出しを行って、後続の操作のためにユーザー PIN をキャッシュできます。

1. CSP によって既に認識されているスマート カードごとに、保存されている SCARDHANDLE を更新し、次のチェックを行います。
   1. スマート カードが削除された場合は、検索を続行します
   2. スマート カードが存在するが、既に名前付きコンテナーがある場合は、検索を続行します
   3. スマート カードを使用できるが、CardQueryFreeSpace の呼び出しで、スマート カードに追加のキー コンテナーのストレージが不足していることが示されている場合は、検索を続行します。
   4. それ以外の場合は、コンテナーの作成に上記の条件を満たす最初の使用可能なスマート カードを使用します
2. 一致するスマート カードが CSP キャッシュに見つからない場合は、スマート カード サブシステムを呼び出します。 列挙されたスマート カードのフィルター処理に使用されるコールバックは、候補のスマート カードに名前付きコンテナーがまだないことを確認し、CardQueryFreeSpace はスマート カードに追加のコンテナーに十分な領域があることを示します。 適切なスマート カードが見つからない場合は、スマート カードを挿入するように求められます。

コンテナーを削除する

1. 指定したコンテナー名が NULL の場合、既定のコンテナーが削除されます。 既定のコンテナーを削除すると、新しい既定のコンテナーが任意に選択されます。 このため、この操作は推奨されません
2. CSP によって既に認識されているスマート カードごとに、保存されている SCARDHANDLE を更新し、次のチェックを行います。
   1. スマート カードに名前付きコンテナーがない場合は、検索を続行します
   2. スマート カードに名前付きコンテナーがあるが、スマート カード ハンドルが無効になった場合は、一致するスマート カードのシリアル番号を格納し、SCardUI に渡します
3. 一致するスマート カードが CSP キャッシュに見つからない場合は、スマート カード サブシステムを呼び出します。 列挙されたスマート カードをフィルター処理するために使用されるコールバックは、候補のスマート カードに名前付きコンテナーがあることを確認する必要があります。 以前のキャッシュ検索の結果としてシリアル番号が指定された場合、コールバックは、コンテナーの一致ではなく、シリアル番号で列挙されたスマート カードをフィルター処理する必要があります。 コンテキストがサイレントでなく、適切なスマート カードが見つからない場合は、スマート カードを挿入するようにユーザーに求める UI を表示します。

Windows でのベース CSP と KSP ベースのアーキテクチャ

次の図は、Windows オペレーティング システムで使用される暗号化アーキテクチャを示しています。

Windows のベース CSP とスマート カード KSP プロパティ

注

API 定義は、WinCrypt.h と WinSCard.h にあります。

プロパティ	説明
PP_USER_CERTSTORE	- スマート カードのすべてのユーザー証明書を含む を返HCERTSTOREすために使用します - 読み取り専用 (によって CryptGetProvParamのみ使用されます) - 証明書ストアを閉じる責任を持つ呼び出し元 - または を使用して PKCS_7_ASN_ENCODING エンコードされた証明書 X509_ASN_ENCODING - CSP は証明書に設定 KEY_PROV_INFO する必要があります - 証明書ストアはメモリ内ストアと見なす必要があります - 証明書はプロパティとして有効 CRYPT_KEY_PROV_INFO である必要があります
PP_ROOT_CERTSTORE	- 読み取りと書き込み (および CryptSetProvParamでCryptGetProvParam使用) - ルート証明書のコレクションをスマート カードに書き込むか、スマート カードからのルート証明書を含む を返すためにHCERTSTORE使用します。 - 主にスマート カードを使用してドメインに参加するために使用されます - 証明書ストアを閉じる責任を持つ呼び出し元
PP_SMARTCARD_READER	- 読み取り専用 (によって CryptGetProvParamのみ使用されます) - スマート カード リーダー名を ANSI 文字列として返します。これは、完全修飾コンテナー名 (つまり、スマート カード リーダーとコンテナー) の構築に使用されます。
PP_SMARTCARD_GUID	- スマート カード GUID (シリアル番号とも呼ばれます) を返します。これはスマート カードごとに一意である必要があります - ルート証明書のソースを追跡するために証明書伝達サービスによって使用されます
PP_UI_PROMPT	- カード挿入ダイアログ ボックスの検索文字列をSCardUIDlgSelectCard設定するために使用します - 設定されているプロセス全体に対して永続的 - 書き込み専用 (によって CryptSetProvParamのみ使用されます)

Windows での CSP への影響

カスタム スマート カード CSP を含む暗号化サービス プロバイダー (CSP) は引き続きサポートされますが、この方法はお勧めしません。 スマート カード用のスマート カード ミニドライバー モデルで既存の Base CSP とスマート カード KSP を使用すると、パフォーマンスと PIN とデータ キャッシュの面で大きな利点が得られます。 CryptoAPI レイヤーと CNG レイヤーで動作するように 1 つのミニドライバーを構成できます。 これにより、楕円曲線暗号化や AES など、強化された暗号化サポートの利点が得られます。

スマート カードが CSP とスマート カード ミニドライバーによって登録されている場合は、最近インストールされたものを使用してスマート カードと通信します。

スマート カード ミニドライバー、CSP、または KSP を記述する

CSP と CSP は、現在のスマート カード ミニドライバー アーキテクチャで特定の機能を使用できない場合にのみ記述されます。 たとえば、スマート カード ミニドライバー アーキテクチャはハードウェア セキュリティ モジュールをサポートしているため、ハードウェア セキュリティ モジュール用にミニドライバーを記述できます。また、基本 CSP またはスマート カード KSP に実装されていないアルゴリズムをサポートする必要がない限り、CSP または KSP は必要ない場合があります。

スマート カード ミニドライバー、CSP、または KSP を記述する方法の詳細については、「スマート カード ミニドライバー」を参照してください。