"論理" レイアウトは、Base CSP/KSP に提示されたデータ レイアウトです。 このレイアウトでは、人間が判読できる名前が使用され、ファイルはカードが使用する物理レイアウトのファイルと 1 対 1 で対応していない可能性があります。
ファイルの名前付けの要件
ファイル名は、最大 8 つの ANSI 文字 (8 ビット) で構成されます。ただし、Windows ファイルとディレクトリの名前付け規則で許可されていない文字は除きます。 ディレクトリ構造は、ルート ディレクトリとアプリケーションが使用するディレクトリの 2 つのレベルで構成されます。 ディレクトリ名は、最大 8 文字の ANSI 文字で構成されます。 大文字と小文字を区別しないファイル名とディレクトリ名を生成するには、カード ミニドライバーの実装で文字列を小文字に変換する必要があります。
ファイルの名前付けの仮想化
ディレクトリとファイルをカード上の適切な場所にマップする仮想ファイル システムをカード ミニドライバーに実装することは許容されます。 通常の操作中に書き込み操作を許可しないカード (National ID カードなど) は、書き込み操作をシミュレートできますが、カードの挿入中に "書き込まれる" ファイルを保持し、読み取るときにこれらのファイルを返すことができる必要があります。
物理カード のデータ レイアウト
カード上のファイルに関する次の情報は、カードとファイル システムの使用方法の概要です。 カード ミニドライバーは、これらのファイルまたはその内容に関する知識を持って設計する必要はありません。 カード ミニドライバーは、一般化されたインターフェイス レイヤーとして記述する必要があります。
論理データ レイアウト
カード識別子
カード識別子は、カードの一意の識別子です。 UI でユーザーに何らかの形式で表される場合がありますが、それ以外の場合は、カードの ID を確立するために参照値との比較にのみ使用されます。 この値は、カードがユーザー向けに準備されるときに割り当てられます。 これはバイト配列として編成されます。
ファイル名
このファイルの論理名は "CardId" です。 これはルート ディレクトリにあります。
アクセス条件
このファイルのアクセス条件は、E(R)、U(R)、A(RW) です。
内容
ファイルは 16 バイトの配列として編成されます。 不透明なバイナリ データとして扱う必要があります。
解説
この値は、カードに対して一意の値が生成されることを保証するために、Microsoft ソフトウェアによって割り当てられます。 製造時にカードに割り当てることができるシリアル番号とは無関係です。
アプリケーション ディレクトリ
アプリケーション ディレクトリ ファイルは、固定長のアプリケーション名エントリの一覧で構成されます。 アプリケーション ディレクトリ名は、アプリケーションのすべてのファイルを含む論理サブディレクトリの名前です。 CAPI2 を使用するアプリケーションの場合、名前は "mscp" で、インデックス値は 0 です。
論理名
このファイルの論理名は "cardapps" です。 これはルート ディレクトリにあります。
アクセス条件
このファイルのアクセス条件は、E(R)、U(RW)、A(RW) です。
内容
ファイルは、バイト インデックスとそれに続く 0 で終わるアプリケーション名文字列 (ANSI) を含む一連のレコードとして編成されます。
解説
アプリケーションの実装では、アプリケーション名がカード上の一意のディレクトリにマップされ、カード キャッシュ ファイル内のアプリケーションのデータの一意のインデックスにもマップされている必要があります。 カード アプリケーション ディレクトリを使用すると、アプリケーションは、アプリケーション ディレクトリ内でその名前を検索し、これが発生する位置のインデックスを書き込むことで、キャッシュ ファイル内でそのインデックス値を見つけることができます。 ファイルは、アプリケーション名を含む 8 バイトのレコードで構成され、末尾にゼロが入力されます。 アプリケーション名では、結果の文字列を 0 で終える必要がないように、8 バイトすべてを使用できます。 したがって、"作成済み" カードのファイルの内容は次の 8 バイトです。
{‘mscp’,0,0,0,0}
キャッシュ ファイル
パフォーマンスを向上させ、カードとの通信を減らすために、Base CSP/KSP はカード データをさまざまな方法でキャッシュできます。 キャッシュ ファイルは、カード上のデータのバージョン番号を示すことによって、ベース CSP/KSP 内のキャッシュ サブシステムの操作を制御するために使用されます。 データが変更されると、この値がインクリメントされます。 キャッシュ ファイルの内部コピーとカードから読み取られたバージョンを比較すると、Base CSP/KSP は、キャッシュされたデータを使用できるかどうか、または更新する必要があるかどうかを判断できます。 この決定を行う必要性は、カードの引き出しや再挿入など、さまざまな理由で発生する可能性があります。
カード識別子とキャッシュ ファイルをカードから読み取れば、ホスト上で不確定な期間キャッシュされた情報を使用できるようになります。
論理名
このファイルの論理名は "CardCF" です。 これはルート ディレクトリにあります。
アクセス条件
このファイルのアクセス条件は、E(R)、U(RW)、A(RW) です。
内容
ファイルは、2 バイト値の形式でグローバル データに編成され、その後、アプリケーションが保持および解釈する 32 ビット キャッシュ値が連続して続きます。 これらの1つ目は、ベースCSP/KSPによって使用されるために予約されています。 その後、各アプリケーションには 1 つの DWORD が割り当てられます。
typedef struct _CARD_CACHE_FILE_FORMAT
{
BYTE bVersion; // Cache version
BYTE bPinsFreshness; // Card PIN
WORD wContainersFreshness;
WORD wFilesFreshness;
} CARD_CACHE_FILE_FORMAT, *PCARD_CACHE_FILE_FORMAT;
解説
アプリケーションの内部キャッシュは、アプリケーションの内部にあるキャッシュ データ コピーが、カードから読み取られたファイルとは異なるバージョン番号のデータを示している場合に更新されます。 キャッシュは通常、カードを使用して各トランザクションの開始時にチェックされます。
アプリケーション キャッシュ データ DWORD の配列 (キャッシュ アプリケーションごとに 1 つ) は、アプリケーション ディレクトリ ファイルのアプリケーション インデックスによってインデックスが作成されます。 アプリケーションが追加されると、ファイルは 4 バイトずつ増加します。
コンテナー マップ ファイル
コンテナー マップ ファイルは、ベース CSP/KSP によって所有され、CONTAINERMAPRECORD 型のレコードの数で構成されます。 これらのレコードは、コンテナー識別子を関連付けます。これは通常、CAPI によって割り当てられた GUID であり、そのコンテナーのキーと証明書にアクセスするために使用できるインデックスに割り当てられます。
ファイル内のレコードの位置 (インデックス) は、そのコンテナーに関連付けられている証明書とキー情報のインデックスに対応します。 したがって、このようなファイルの 2 番目のレコードには、0 から始まるインデックス 1 が表示されます。
このコンテナーに関連付けられている証明書と、コンテナーの署名キーまたはキー交換キーはすべて、このインデックス (UserCerts\SignatureCert1、SignatureKey1 など) を共有します。 レコードには、そのインデックスに関連付けられているキーのコンテナー GUID とサイズ情報が含まれます。
論理名
このファイルの論理名は "CMapFile" です。 これは "mscp" ディレクトリにあります。
アクセス条件
このファイルのアクセス条件は、E(R)、U(RW)、A(RW) です。
内容
このファイルのアクセス条件は、E(R)、U(RW)、A(RW) です。
解説
このファイルは、Base CSP/KSP によって作成され、そのコンテンツが保持されます。 このファイルの内部構造に関する情報は、参照のみを目的として提供されます。 ファイル内のレコードの形式は次のとおりです。
CONTAINERMAPRECORD
これらのレコードには、CAPI によって割り当てられたコンテナー GUID と、そのコンテナーに関連付けられている関連付けられているキー交換キーまたは署名キーのキー サイズが含まれます。 すべての WORD メンバーはリトル エンディアンバイト順です。
//
// Type: CONTAINER_MAP_RECORD
//
// This structure describes the format of the Base CSP's
// container map file, stored on the card. This is well-known
// logical file wszCONTAINER_MAP_FILE. The file consists of
// zero or more of these records.
//
#define MAX_CONTAINER_NAME_LEN 39
// This flag is set in the CONTAINER_MAP_RECORD bFlags
// member if the corresponding container is valid and currently
// exists on the card. // If the container is deleted, its
// bFlags field must be cleared.
#define CONTAINER_MAP_VALID_CONTAINER 1
// This flag is set in the CONTAINER_MAP_RECORD bFlags
// member if the corresponding container is the default
// container on the card.
define CONTAINER_MAP_DEFAULT_CONTAINER 2
typedef struct _CONTAINER_MAP_RECORD
{
WCHAR wszGuid [MAX_CONTAINER_NAME_LEN + 1];
BYTE bFlags;
BYTE bReserved;
WORD wSigKeySizeBits;
WORD wKeyExchangeKeySizeBits;
} CONTAINER_MAP_RECORD, *PCONTAINER_MAP_RECORD;
wszGuid メンバーは、CAPI がコンテナーに割り当てた識別子の UNICODE 文字列表現で構成されます。 通常、これは GUID 文字列ですが、常にではありません。 識別子名に特殊文字 "\" を含めることはできません。 読み取り専用カードをプロビジョニングする場合、プロビジョニング プロセスは識別子名の同じガイドラインに従う必要があります。
コンテナー名は null で終わる必要があり、NULL ターミネータを含む長さが (MAX_CONTAINER_NAME_LEN + 1) 文字を超えてはなりません。
このテーブルからレコードを削除する必要がある場合は、レコードにゼロを書き込むことでエントリが無効になります。 このようなレコードは、後で新しいデータによって上書きできます。 非アクティブなエントリを削除するためにテーブルが "パック" されていません。
Flags バイトでは、次のビットが有効です。
- ビット 0 は、コンテナー レコードが有効な場合に設定されます。
- コンテナーが既定の場合、ビット 1 が設定されます。 このビットをいつでも設定できるのは、コンテナー マップ内の 1 つのレコードだけです。 このビットは、ビット 0 も設定されている場合にのみ設定できます。 つまり、無効な既定のコンテナーを持つことはできません。 他のすべてのビットは、現在、カード ミニドライバーの将来のリビジョンのために予約されています。
- 既定のコンテナーの場合、これはバイト 0x03に変換されます。 既定値ではない有効なコンテナーの場合、この値は0x01。
- ビット 2 から 7 は、将来使用するために予約されています。
データ レイアウトの概要
次の表は、一般的な実装のカード ミニドライバーと Base CSP/KSP の間のインターフェイスにあるデータの編成をまとめたものです。 "論理名" は、Base CSP/KSP がカード ミニドライバーとの通信に使用する文字列です。カード上の対応する要素に直接マップされる場合と、マップされない場合があります。
証明書とキーは、実際のファイル名のインデックスのみを使用して、目的に応じて Base CSP/KSP によって論理的にサブディレクトリにグループ化されることに注意してください。 カードに追加されるすべての証明書またはキーには、ディレクトリ内のインデックス番号に従って名前が付けられます。 証明書とキーの例を説明のために次の表に示します。
ディレクトリ名 | ファイル名 | タイプ | アクセス条件 | コメント |
---|---|---|---|---|
<根> | cardid | ファイル | E(R) U(R) A(RW) | カード識別子 |
<根> | cardcf | ファイル | E(R) U(RW) A(RW) | キャッシュ ファイル |
<根> | カードアプリ | ファイル | E(R) U(R) A(RW) | アプリケーション名によるディレクトリ インデックス。 詳細については、「アプリケーション ディレクトリ」を参照してください。 |
mscp | Dir | E(R) U(RW) A(RW) | ベース CSP/KSP アプリ ディレクトリ | |
mscp | cmapfile | ファイル | E(R) U(RW) A(RW) | インデックスを作成する CAPI GUID |
mscp | kxc00 | ファイル | E(R) U(RW) A(RW) | (例) キー交換証明書 0 |
mscp | ksc00 | ファイル | E(R) U(RW) A(RW) | (例) キー署名証明書 0 |
mscp | ksc01 | ファイル | E(R) U(RW) A(RW) | (例) キー署名証明書 1 |
mscp | msroots | ファイル | E(R) U(RW) A(RW) | エンタープライズの信頼されたルート |
手記 msroots との相互運用性: mscp\msroots ファイルは PKCS #7 形式の証明書ストアです。
ファイル アクセス制御
既知のプリンシパル
既知の主体は、カード データにアクセスしようとするさまざまな種類のユーザーを識別するものです。 次の表に、有効なプリンシパルと、データ アクセス操作識別子と共に使用してアクセス条件を定義できる 1 文字の省略形を示します。 より識別可能なプリンシパルが存在する可能性がありますが、一覧は、Base CSP/KSP とカード ミニドライバーの間の通信に意味を持つものに制限されます。
名前 | 説明 | 記憶法 | PIN_ID マッピング |
---|---|---|---|
皆さん | 認証されていない (または匿名の) ユーザーを含むすべての要求者。 | E | ROLE_全員 (0) |
ユーザー | カードのユーザー クライアント。PIN を使用して自分の ID をカードに証明します。 | U | 役割_ユーザー (1) |
管理者 | カード発行者またはカード上のカードまたはデータに対する管理上の関係を持つ他の当事者。 特殊な PIN または KEY (カードまたはユーザーに固有の場合もあります) を使用して、PIN のブロック解除など、このデータを使用せずにユーザーが実行できない管理タスクを実行します。 | ある | ROLE_ADMIN (2) |
次の説明で "everyone" を使用する場合、通常は、認証されているかどうかに関係なく、カードの任意のユーザーを意味します。 たとえば、"すべてのユーザーがファイルを読み取ることができます" とは、ユーザーまたは管理者がファイルを自動的に読み取ることができることを意味します。
ファイル システム アクセスの場合、管理者は通常、"スーパー ユーザー" と見なされ、ユーザーと同じ特権をすべて持っています (実行特権を除く)。
ディレクトリ アクセス条件
プリンシパルは、2 セットのアクセス許可を持つカード ファイル システムにディレクトリを作成できます。 次の表は、各アクセス許可の効果をまとめたものです。
ディレクトリ アクセス条件 | 意味 |
---|---|
ユーザー作成削除ディレクトリAc | ユーザーと管理者は、 CardCreateFile を使用してディレクトリにファイルを作成できます。 ユーザーと管理者は、 CardDeleteDirectory を呼び出すことによってディレクトリを削除できます (空でない場合)。 すべてのユーザーが CardEnumFiles を使用してディレクトリの内容を一覧表示できます。 |
管理者作成削除ディレクトリアクション | 管理者は CardCreateFile を使用してディレクトリにファイルを作成できます。 管理者は CardDeleteDirectory を使用してディレクトリを削除できます。 すべてのユーザーが CardEnumFiles を使用してディレクトリの内容を一覧表示できます。
手記 この ACL は省略可能です。 スマート カード ミニドライバー仕様の今後の改訂から削除される可能性があります。
|
手記 ディレクトリを作成すると、すべてのユーザーにディレクトリ内のファイルを一覧表示するアクセス許可が自動的に付与されます。 ディレクトリに対する個別の "リスト" アクセス許可はありません。
ファイル アクセス操作
プリンシパルは、さまざまな方法でファイルの内容を使用できます。 有効な操作を次の表に示します。この省略形は 1 文字で、プリンシパル指定子と共に使用してアクセス条件を定義できます。 特に、Execute (X) には他のファイル アクセス操作との論理的な関係はなく、独立した操作であることに注意してください。
操作/特権 | 説明 | 記憶法 |
---|---|---|
お読みください | ファイルの内容を直接、または書式設定または処理されたフォームで受け取ります。 |
R |
書く | ファイルの内容を変更し、場合によってはファイルを作成するか、既存のデータを削除、置換、または変更します。 |
W |
実行する | カードが要求元の代理として行う操作に、ファイルの内容を使用します。ただし、使用されたデータを受け取ることができず、またそれを実行可能な形で推測することもできません。 |
X |
ファイル アクセス条件
アクセス条件は ACL に似ています。 アクセス条件は、特定のファイルにアクセスできるプリンシパルと、実行できる操作を制御します。 カード上の各ファイルには、プリンシパルとそのアクセス特権の一覧で記述できるアクセス条件があります。 プリンシパルまたは特権が説明に含まれていない場合は、拒否されると見なされます。 一般に、アクセス条件はカードに適用されます。
次の表に、 CardCreateFile で使用できるアクセス条件を示し、適切なアクセス条件ニーモニックにマップします。
ファイル アクセス条件 | 実際の意味 | アクセス条件ニーモニック |
---|---|---|
InvalidAc | ACL の取得中にエラーが発生しました。 |
|
EveryoneReadUserWriteAc | つまり、すべてのユーザーがファイルを読み取ったり、ファイル情報 (CardReadFile または CardGetFileInfo) を取得したり、ユーザーと管理者がファイルの読み取り、ファイルの書き込み、ファイルの削除を行うことができます。 |
E(R)、U(RW)、A(RW) |
UserWriteExecuteAc | ユーザーはファイルを書き込み、ファイルを "実行" でき、ファイルを削除できます。 ユーザーを含め、ファイルの内容を読み取ることができるユーザーはいません。 管理者は、このファイルの内容を書き込むことができますが、実行することはできません。また、ファイルを削除することもできます。 |
U(WX) A(W) |
EveryoneReadAdminWriteAc | つまり、すべてのユーザーがファイルを読み取ったり、ファイル情報 (CardReadFile または CardGetFileInfo) を取得したりできますが、管理者のみがファイルを書き込んでファイルを削除できます。 |
E(R)、U(R)、A(RW) |
UnknownAc | ファイルは、定義済みの AC タイプの 1 つではないカードのアクセス条件 (AC) によって保護されます。 |
|
UserReadWriteAc | 全員アクセス不可 // ユーザー読み取り書き込み // // 例: パスワードウォレットファイル |
U(RW)、A(RW) |
AdminReadWriteAc | 全員/ユーザー アクセス不可 管理者の読み取り書き込み // 例: 管理データ。 |
A(RW) |
次の表に、一般的な項目のサンプル アクセス条件を示します。
アクセス条件 | 説明 |
---|---|
E(X) U(W) A(W) | これは、ユーザー PIN のアクセス条件になります。 PIN を必要とする操作が開始されると、ユーザーは識別されません。 ユーザーの ID を確立するには、PIN を "実行" する必要があります。 PIN の入力後、ユーザーの ID は E から U に昇格されます。ユーザーと管理者の両方が PIN を記述できます。 |
U(WX) A(W) | ユーザーの秘密キー ファイルがカードから読み取られることはなく、その内容を暗号化操作に使用できるのはユーザーだけです。 このデータは、ユーザーまたは管理者によって変更される場合があります。 |
E(R) U(R) A(RW) | カード識別子。 |
ディレクトリとファイル のアクセス条件に関する注意事項
- CardGetFileInfo が成功するためには、プリンシパルがファイルに対する読み取りアクセス権を持っている必要があります。
- ディレクトリの内容を一覧表示するための個別のリスト権限はありません。
- "ディレクトリにアクセスを作成する" とは、ディレクトリ内にファイルを作成する権限を持つことを意味し、"ディレクトリのアクセス権を削除する" とは、ディレクトリ自体を削除する権限を持つことを意味します。 ファイルを削除するには、カード プリンシパルがファイル自体への書き込みアクセス権を持っている必要があります。
- スマート カード ミニドライバー インターフェイスを使用して、E(W) アクセス許可を持つディレクトリを作成することはできません。
- スマート カード ミニドライバー インターフェイスを使用して、ファイルまたはディレクトリを削除して再作成せずにファイルまたはディレクトリのアクセス許可を変更することはできません。
- スマート カード ミニドライバー インターフェイスを使用して、管理者または認証されていないユーザーが所有する秘密キー ファイルを作成することはできません。
- スマート カード ミニドライバー インターフェイスを使用して、カード (E(X)、U(W)、A(W)) に PIN ファイルを作成することはできません。
- スマート カード ミニドライバー インターフェイスを介してディレクトリ アクセス条件を照会することはできません。
- スマート カード ミニドライバー インターフェイスを介してのみ、使用可能なアクセス条件の組み合わせのサブセットを含むファイルを作成できます。