ファイルシステムの要件

2025-05-30

"論理" レイアウトは、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 は省略可能です。スマートカードミニドライバー仕様の今後の改訂から削除される可能性があります。

ユーザー作成削除ディレクトリ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 ファイルを作成することはできません。
スマートカードミニドライバーインターフェイスを介してディレクトリアクセス条件を照会することはできません。
スマートカードミニドライバーインターフェイスを介してのみ、使用可能なアクセス条件の組み合わせのサブセットを含むファイルを作成できます。

次の方法で共有

ファイル システムの要件

ファイルの名前付けの要件

ファイルの名前付けの仮想化

物理カード のデータ レイアウト

論理データ レイアウト

カード識別子

アプリケーション ディレクトリ

キャッシュ ファイル

コンテナー マップ ファイル

データ レイアウトの概要

ファイル アクセス制御

既知のプリンシパル

ディレクトリ アクセス条件

ファイル アクセス操作

ファイル アクセス条件

ディレクトリとファイル のアクセス条件に関する注意事項

フィードバック

その他のリソース

ファイルシステムの要件

物理カードのデータレイアウト

論理データレイアウト

アプリケーションディレクトリ

キャッシュファイル

コンテナーマップファイル

データレイアウトの概要

ファイルアクセス制御

ディレクトリアクセス条件

ファイルアクセス操作

ファイルアクセス条件

ディレクトリとファイルのアクセス条件に関する注意事項