2.5. Certificate System を使用したスマートカードトークン管理

スマートカード は、暗号化証明書および鍵を含むハードウェア暗号化デバイスです。ユーザーは、セキュアな Web アクセスやセキュアなメールなどの操作に参加できます。また、Red Hat Enterprise Linux などのさまざまなオペレーティングシステムにログインする認証デバイスとしても機能します。サービスの有効期間全体でこれらのカードまたはトークンを管理することは、トークン管理システム (TMS) によって行われます。
TMS 環境には、認証局 (CA)、トークンキーサービス (TKS)、およびトークン処理システム (TPS) と、サーバー側のキー生成およびキーのアーカイブとリカバリーのための任意のキーリカバリー機関 (KRA) が必要です。OCSP (Online Certificate Status Protocol) を使用して、オンライン証明書ステータス要求に対応する CA と連携することもできます。この章では、Red Hat Certificate System のスマートカード管理機能を提供する TKS システムおよび TPS システムと、ユーザー側から TMS と連携する Enterprise Security Client (ESC) の概要を説明します。

図2.4 TMS スマートカードの管理方法

TMS スマートカードの管理方法

2.5.1. トークンキーサービス (TKS)

Token Key Service (TKS) は、1 つ以上のマスターキーを管理します。これは マスターキー を維持し、キー資料にアクセスできる TMS 内の唯一のエンティティーです。運用環境では、有効な各スマートカードトークンには、マスターキーと、カード (CUID) に固有の ID の両方から派生した対称鍵のセットが含まれます。
最初に、対称キーのデフォルト (製造元のマスターキーごとにのみ一意) のセットが、製造元によって各スマートカードで初期化されます。このデフォルトのセットは、Key Changeover 操作を実行して TKS で新しいマスターキーを生成することで、デプロイメントサイトで変更する必要があります。マスターキーの唯一の所有者として、スマートカードの CUID が付与されると、TKS はその特定のスマートカードにある対称キーのセットを導出できます。これにより、TKS は、TMS と個々のスマートカード間の安全な通信用にセッションベースの セキュアチャネル を確立できます。
注記
TKS が管理するデータの機密性により、TKS はアクセスが制限されたファイアウォールの背後に設定する必要があります。

2.5.1.1. マスターキーおよびキーセット

TKS は、複数のスマートカードの鍵セットをサポートします。各スマートカードベンダーは、スマートカードトークンストックに対して異なるデフォルト (開発者) の静的キーセットを作成し、TKS には、空白のトークンのフォーマットプロセスを開始するための静的キーセット (メーカーごと) が装備されています。
空白のスマートカードトークンのフォーマットプロセス中に、Java アプレットと一意に派生した対称キーセットがトークンに挿入されます。TKS がサポートする各マスターキー (場合によっては keySet と呼ばれます) には、TKS 設定ファイル (CS.cfg) にエントリーセットがあります。各 TPS プロファイルには、TMS とスマートカードトークン間のセッション固有のキーのセットによってセキュリティーが保護された Secure Channel の確立を本質的に担当する、一致するキー導出プロセスの適切な TKS キーセットに登録を指示する設定が含まれています。
TKS では、マスターキーは TPS の参照用に名前付きの keySet によって定義されます。TPS では、登録タイプ (内部または外部の登録) に応じて、keySet は TPS プロファイルで指定されます。または、keySet Mapping Resolver で決定されます。

2.5.1.2. キー階層 (共有キートランスポート)

キーセレモニー は、機密性の高いキーをある場所から別の場所に安全な方法で転送するためのプロセスです。1 つのシナリオでは、非常に安全なデプロイメント環境では、外部へのネットワークのないセキュアな vault でマスターキーを生成できます。組織が、異なる物理マシンに TKS インスタンスと TPS インスタンスを持つ場合があります。いずれの場合も、キーを信頼できる人が 1 人もいないという前提の下で、Red Hat Certificate System TMS は、安全な鍵の送信を管理する tkstool と呼ばれるユーティリティーを提供します。

2.5.1.3. キー更新 (キーの切り替え)

Global Platform 準拠のスマートカードをファクトリーに作成すると、製造元はデフォルトの対称鍵をトークンに作成します。TKS は、最初にこの対称鍵を使用するように設定されています (TKS 設定のベンダーごとに KeySet エントリーが 1 つ)。しかし、これらの対称鍵は同一ストックのスマートカードに固有のものではなく、周知の鍵であるため、トークンを操作できるエンティティーセットを制限するために、製造元で共有されていない、トークンごとに固有のセットに置き換えることが強く推奨されます。
キーの変更は、Token Key Service サブシステムのサポートにより行われます。TKS の関数の 1 つは、以前に説明したスマートカードトークンキーが派生しているマスターキーを確認することです。TKS の制御下に複数のマスターキーが存在する可能性があります。
重要
このキー切り替えプロセスがトークンに対して実行されると、デフォルトのキーセットが有効でなくなったため、トークンは将来使用できなくなる可能性があります。トークンをプロビジョニングした TPS および TKS システムが有効である限り、鍵は基本的に有効です。このため、マスターキーのいずれかが古くなっている場合でも、すべてのマスターキーを保持することが不可欠です。
TKS の古いマスターキーを無効にして、適切に制御できますが、無効にしたトークンがプランの一部である限り削除しないでください。トークンキーを元のキーセットに戻すためのサポートがあります。これは、ある種のテストシナリオでトークンを再利用する場合に実行可能です。

2.5.1.4. APDU およびセキュアチャンネル

Red Hat Certificate System Token Management System (TMS) は GlobalPlatform スマートカード仕様をサポートしており、マスターキーを管理する Token Key System (TKS) と、Application Protocol Data Units (APDU) を使用してスマートカード (トークン) と通信する Token Processing System (TPS) で Secure Channel の実装が行われます。
APDU には、以下の 2 つのタイプがあります。
  • コマンド APDU (TPS からスマートカードに送信)
  • レスポンス APDU (スマートカードから TPS にレスポンスとして送信)
APDU コマンドの開始は、クライアントがアクションを実行し、要求のために Certificate System サーバーに接続したときにトリガーされる場合があります。安全なチャネルは、TPS からスマートカードトークンに送信される InitializeUpdate APDU で始まり、ExternalAuthenticate APDU で完全に確立されます。次に、トークンと TMS の両方が、セッションキーと呼ばれる共有シークレットのセットを確立します。これは、通信の暗号化と認証に使用されます。この認証および暗号化された通信チャネルは Secure Channel と呼ばれます。
TKS は、一意の対称オントークンスマートカードキーのセットを取得できるマスターキーにアクセスできる唯一のエンティティーであるため、Secure Channel は、TMS と個々のトークンとの間の適切に保護された通信を提供します。チャンネルの接続解除には、新しいチャンネルに対する新しいセッションキーの再確立が必要になります。

2.5.2. トークン処理システム (TPS)

Token Processing System (TPS) は、スマートカード証明書登録の登録認証局です。これは、クライアント側のスマートカードトークンと対話するユーザー中心のエンタープライズセキュリティークライアント (ESC) と、認証局 (CA) やキーリカバリー機関 (KRA) などの Certificate System バックエンドサブシステムとの間のパイプ役として機能します。
TMS では、スマートカードを管理するために TPS が必要です。これは、TPS が APDU コマンドと応答を理解する唯一の TMS エンティティーであるためです。TPS は、スマートカードにコマンドを送信して、ユーザーやデバイスなどの特定のエンティティーのキーと証明書を生成および保存できるようにします。スマートカード操作は TPS を経由して、証明書を生成するために CA や、鍵を生成、アーカイブ、または復元する KRA などのアクションのために適切なサブシステムに転送されます。

2.5.2.1. Coolkey アプレット

Red Hat Certificate System には、TMS 対応スマートカードトークンで実行するために作成された Coolkey Java アプレットが含まれています。Coolkey アプレットは、証明書およびキー関連の操作を処理する PKCS#11 モジュールに接続します。トークンフォーマットの操作時に、このアプレットは Secure Channel プロトコルを使用してスマートカードトークンに挿入され、設定ごとに更新できます。

2.5.2.2. トークン操作

Red Hat Certificate System の TPS は、スマートカードのエンドユーザーの代わりにスマートカードをプロビジョニングすることができます。Token Processing System は、以下の主要なトークン操作をサポートします。
  • トークンフォーマット: フォーマット操作は、適切な Coolkey アプレットをトークンにインストールします。アプレットは、後続の暗号鍵と証明書を後で配置できるプラットフォームを提供します。
  • トークンの登録: 登録操作により、必要な暗号鍵と暗号証明書でスマートカードが生成されます。この資料により、スマートカードのユーザーは、セキュアな Web サイトアクセスやセキュアなメールなどの操作に参加できます。登録には 2 つのタイプがサポートされています。これは、グローバルに設定されます。
    • 内部登録: プロファイル マッピングリゾルバー で決定される TPS プロファイルで登録します。
    • 外部登録: ユーザーの LDAP レコードのエントリーで、TPS プロファイルで登録を行います。
  • トークンの PIN リセット: トークンの PIN リセット操作により、トークンのユーザーはトークンへのログインに使用される新しい PIN を指定でき、暗号化操作を実行できます。
以下の他の操作は、上記の主な操作に対して補助または固有の操作として考慮できます。これらは、関連する設定ごとに、またはトークンの状態によってトリガーできます。
  • キー生成: 各 PKI 証明書は、公開鍵と秘密鍵のペアで設定されます。Red Hat Certificate System では、TPS プロファイル の設定に応じて、鍵の生成は 2 つの方法で実行できます。
    • トークン側のキー生成: PKI キーペアがスマートカードトークンで生成されます。トークン側でキーペアを生成すると、キーのアーカイブが許可 されません
    • サーバー側のキー生成: PKI キーペアは TMS サーバー側で生成されます。その後、キーペアはセキュアチャネルを使用してトークンに送信されます。サーバー側で鍵のペアを生成すると、キーのアーカイブが可能になります。
  • 証明書の更新: この操作により、以前登録したトークンが同じ鍵を再度使用している間にトークンに現在発行された証明書を使用できるようになります。これは、古い証明書の有効期限が切れて、新しい証明書を作成したいが、元のキーマテリアルを維持したい場合に役立ちます。
  • 証明書失効リスト: TPS プロファイル設定またはトークンの状態をもとに、証明書失効リストをトリガーできます。
    通常、証明書を発行した CA のみがそれを取り消すことができます。つまり、CA を廃止すると、特定の証明書を取り消すことができなくなります。ただし、トークンの失効要求をリタイアした CA にルーティングしながら、登録などの他のすべての要求を新しいアクティブな CA にルーティングすることは可能です。このメカニズムは 取り消しルーティン と呼ばれます。
  • トークンキーの切り替え: フォーマット操作によってトリガーされるキーの変更操作により、トークンの内部キーを、デフォルトの開発者キーセットから、トークン処理システムの開発者により制御される新しいキーセットに変更できます。開発者キーセットはテスト状況に適したものであるため、通常、実際のデプロイメントシナリオでこれを行います。
  • アプレットの更新: TMS デプロイメントでは、必要に応じて Coolkey スマートカードアプレットを更新またはダウングレードできます。

2.5.2.3. TPS プロファイル

Certificate System Token Processing System サブシステムは、スマートカードトークンの管理を容易にします。トークンは TPS によってプロビジョニングされ、空白の状態からフォーマット済みまたは登録済みの状態になります。フォーマットされたトークンには、TPS でサポートされる CoolKey アプレットが含まれますが、登録済みトークンは、必要な証明書と暗号化キーを使用して個人にパーソナライズされます (バインディングと呼ばれるプロセス)。この完全にプロビジョニングされたトークンは、暗号化操作に使用する準備ができています。
TPS は プロファイル も管理できます。トークンプロファイルの概念は以下に関連します。
  • トークンのフォーマットまたは登録を行う手順。
  • 操作が正常に完了した後、終了したトークンに含まれる属性。
以下のリストで、一意のトークンプロファイルを設定する数量について説明します。
  • TPS がユーザーの認証 LDAP データベースに接続する方法。
  • このトークン操作にはユーザー認証が必要ですか。その場合に使用する認証マネージャー。
  • TPS は、証明書を取得する Certificate System CA にどのように接続しますか。
  • このトークンで生成された秘密鍵と公開鍵はどのように生成されているか。トークン側またはサーバー側で生成されているか。
  • 秘密鍵と公開鍵を生成する際に使用する鍵のサイズ (ビット単位)。
  • このトークンで証明書を生成するのに使用される証明書登録プロファイル (CA によるプロビジョニング)
    注記
    この設定により、トークンに書き込まれる証明書の最終構造が決定されます。証明書に含まれる拡張機能に基づいて、さまざまな用途に応じてさまざまな証明書を作成できます。たとえば、1 つの証明書はデータ暗号化に特化でき、別の証明書は署名操作に使用できます。
  • トークンで必要となる Coolkey アプレットのバージョン
  • 登録操作のためにこのトークンに配置される証明書の数
上記および他の多くのトークンタイプまたはプロファイルごとに設定できます。利用可能な設定オプションの一覧は、Red Hat Certificate System 管理ガイドを参照してください。
考慮すべきもう 1 つの質問は、ユーザーによってプロビジョニングされている特定のトークンがどのように個々のトークンプロファイルにマップされるかです。登録には、以下の 2 つのタイプがあります。
  • Internal Registration: この場合、TPS プロファイル (tokenType) は、プロファイル Mapping Resolver で決定されます。このフィルターベースのリゾルバーは、トークンが提供するデータをすべて考慮し、ターゲットプロファイルを決定するように設定できます。
  • 外部登録: 外部登録使用する場合、プロファイル (名前のみ。実際のプロファイルは、内部登録で使用されるものと同じ方法で TPS で定義されます) は、認証中に取得される各ユーザーの LDAP レコードで指定されます。これにより、TPS はユーザー情報が保存される外部登録 Directory Server からキーの登録およびリカバリー情報を取得できます。これにより、TPS 内部登録メカニズムに固有の登録、失効、および復旧ポリシーを上書きする制御が可能になります。外部登録に関連するユーザー LDAP レコード属性名は設定可能です。
    グループ証明書という概念が必要な場合には、外部登録が役立ちます。この場合、グループ内のすべてのユーザーには、共有証明書および鍵をダウンロードするために LDAP プロファイルに特別なレコードを設定できます。
使用する登録は、TPS インスタンスごとにグローバルに設定されます。

2.5.2.4. トークンデータベース

Token Processing System は、LDAP トークンデータベースストアを使用します。これは、アクティブなトークンとその証明書のリストを維持し、各トークンの現在の状態を追跡します。ブランドの新しいトークンは Uninitialized とみなされますが、完全登録されたトークンは Enrolled と見なされます。このデータストアは常に更新され、トークンの処理時に TPS によって確認されます。
2.5.2.4.1. トークンの状態および移行
Token Processing System は、現在のトークンステータスとトークンで実行できるアクションを定義するために内部データベースのステータスを保存します。
2.5.2.4.1.1. トークンの状態
以下の表では、可能なトークン状態をすべて紹介します。

表2.9 考えられるトークンの状態

名前 コード ラベル
FORMATTED 0 フォーマット済み (初期化されていない)
DAMAGED 1 物理的に破損
PERM_LOST 2 永続的に失われる
SUSPENDED 3 一時停止 (一時的に失われる)
ACTIVE 4 アクティブ
TERMINATED 6 終了
UNFORMATTED 7 未フォーマット
コマンドラインインターフェイスは、上記の名前を使用してトークンの状態を表示します。グラフィカルインターフェイスは、代わりに Label を使用します。
注記
上記の表には、コード 5 付きの状態は含まれません。以前は削除された状態に属していました。
2.5.2.4.1.2. グラフィカルインターフェイスまたはコマンドラインインターフェイスを使用したトークン状態の移行完了
各トークンの状態には、遷移できる次の状態の数が制限されています。たとえば、トークンは FORMATTED から ACTIVE または DAMAGED に状態を変更できますが、FORMATTED から UNFORMATTED に移行することはできません。
さらに、トークンが遷移できる状態のリストは、遷移がコマンドラインまたはグラフィカルインターフェイスを使用して手動でトリガーされるか、トークン操作を使用して自動的にトリガーされるかによって異なります。許可されている手動遷移のリストは、tokendb.allowedTransitions プロパティーに格納され、tps.operations.allowedTransitions プロパティーコントロールは、ークン動作によってトリガ遷移を可能にしました。
手動およびトークン操作ベースの両方の移行のデフォルト設定は、/usr/share/pki/tps/conf/CS.cfg 設定ファイルに保存されます。
2.5.2.4.1.2.1. コマンドラインインターフェイスまたはグラフィカルインターフェイスを使用したトークン状態の移行
コマンドラインまたはグラフィカルインターフェイスで許可される移行はすべて、tokendb.allowedTransitions プロパティーを使用して TPS 設定ファイルに記載されています。
tokendb.allowedTransitions=0:1,0:2,0:3,0:6,3:2,3:6,4:1,4:2,4:3,4:6,6:7
プロパティーには、トランジションのコンマ区切りリストが含まれます。それぞれの移行は、<current code>:<new code> 形式で記述されます。このコードは 表2.9「考えられるトークンの状態」 で説明されています。デフォルト設定は /usr/share/pki/tps/conf/CS.cfg に保存されます。
以下の表では、可能な各移行の詳細を説明します。

表2.10 可能な手動トークン状態遷移

遷移 現在の状態 次の状態 説明
0:1 FORMATTED DAMAGED このトークンは物理的に破損しています。
0:2 FORMATTED PERM_LOST このトークンは永続的に失われています。
0:3 FORMATTED SUSPENDED このトークンは一時停止されています (一時的で失われています)。
0:6 FORMATTED TERMINATED このトークンは終了しました。
3:2 SUSPENDED PERM_LOST この一時停止されたトークンは永続的に失われています。
3:6 SUSPENDED TERMINATED この一時停止されたトークンは終了しています。
4:1 ACTIVE DAMAGED このトークンは物理的に破損しています。
4:2 ACTIVE PERM_LOST このトークンは永続的に失われています。
4:3 ACTIVE SUSPENDED このトークンは一時停止されています (一時的で失われています)。
4:6 ACTIVE TERMINATED このトークンは終了しました。
6:7 TERMINATED UNFORMATTED このトークンを再利用します。
以下の移行は、トークンの元の状態に応じて自動的に生成されます。トークンが元々 FORMATTED で、SUSPENDED となると、FORMATTED 状態にのみ戻ることができます。トークンが元々 ACTIVE で、SUSPENDED になると、ACTIVE 状態のみに戻ることができます。

表2.11 自動的にトリガーされるトークンの状態遷移

遷移 現在の状態 次の状態 説明
3:0 SUSPENDED FORMATTED この一時停止 (一時的な損失) トークンがあります。
3:4 SUSPENDED ACTIVE この一時停止 (一時的な損失) トークンがあります。
2.5.2.4.1.3. トークン操作を使用したトークン状態遷移
トークン操作を使用して実行できる移行はすべて、tokendb.allowedTransitions プロパティーを使用して TPS 設定ファイルで説明されています。
tps.operations.allowedTransitions=0:0,0:4,4:4,4:0,7:0
プロパティーには、トランジションのコンマ区切りリストが含まれます。それぞれの移行は、<current code>:<new code> 形式で記述されます。このコードは 表2.9「考えられるトークンの状態」 で説明されています。デフォルト設定は /usr/share/pki/tps/conf/CS.cfg に保存されます。
以下の表では、可能な各移行の詳細を説明します。

表2.12 トークン操作を使用した可能なトークン状態遷移

遷移 現在の状態 次の状態 説明
0:0 FORMATTED FORMATTED これにより、トークンの再フォーマットやトークンのアプレット/キーのアップグレードが可能になります。
0:4 FORMATTED ACTIVE これにより、トークンを登録できます。
4:4 ACTIVE ACTIVE これにより、アクティブなトークンを再登録できます。外部の登録に便利です。
4:0 ACTIVE FORMATTED これにより、アクティブなトークンのフォーマットが可能になります。
7:0 UNFORMATTED FORMATTED これにより、空白または以前に使用されたトークンのフォーマットが可能になります。
2.5.2.4.1.4. トークンの状態および遷移ラベル
トークン状態および遷移のデフォルトラベルは、/usr/share/pki/tps/conf/token-states.properties 設定ファイルに保存されます。デフォルトでは、ファイルの内容は以下のようになります。
# Token states
UNFORMATTED         = Unformatted
FORMATTED           = Formatted (uninitialized)
ACTIVE              = Active
SUSPENDED           = Suspended (temporarily lost)
PERM_LOST           = Permanently lost
DAMAGED             = Physically damaged
TEMP_LOST_PERM_LOST = Temporarily lost then permanently lost
TERMINATED          = Terminated

# Token state transitions
FORMATTED.DAMAGED        = This token has been physically damaged.
FORMATTED.PERM_LOST      = This token has been permanently lost.
FORMATTED.SUSPENDED      = This token has been suspended (temporarily lost).
FORMATTED.TERMINATED     = This token has been terminated.
SUSPENDED.ACTIVE         = This suspended (temporarily lost) token has been found.
SUSPENDED.PERM_LOST      = This suspended (temporarily lost) token has become permanently lost.
SUSPENDED.TERMINATED     = This suspended (temporarily lost) token has been terminated.
SUSPENDED.FORMATTED      = This suspended (temporarily lost) token has been found.
ACTIVE.DAMAGED           = This token has been physically damaged.
ACTIVE.PERM_LOST         = This token has been permanently lost.
ACTIVE.SUSPENDED         = This token has been suspended (temporarily lost).
ACTIVE.TERMINATED        = This token has been terminated.
TERMINATED.UNFORMATTED   = Reuse this token.
2.5.2.4.1.5. 許可されるトークンの状態遷移のカスタマイズ
トークン状態遷移の一覧をカスタマイズするには、/var/lib/pki/instance_name/tps/conf/CS.cfg で以下のプロパティーを編集します。
  • コマンドラインまたはグラフィカルインターフェイスを使用して実行できる移行の一覧をカスタマイズするには、tokendb.allowedTransitions
  • トークン操作を使用して許可される移行のリストをカスタマイズするには、tps.operations.allowedTransitions
必要に応じて、移行はデフォルトのリストから削除できますが、デフォルトのリストにない限り、新しい移行を追加することはできません。デフォルトは /usr/share/pki/tps/conf/CS.cfg に保存されます。
2.5.2.4.1.6. トークンの状態と遷移ラベルのカスタマイズ
トークンの状態と遷移ラベルをカスタマイズするには、デフォルトの /usr/share/pki/tps/conf/token-states.properties をインスタンスフォルダー (/var/lib/pki/instance_name/tps/conf/CS.cfg) にコピーし、必要に応じてラベルを変更します。
変更は即座に有効になり、サーバーを再起動する必要はありません。TPS ユーザーインターフェイスは読み込みが必要になる場合があります。
デフォルトの状態およびラベル名に戻すには、編集した token-states.properties ファイルをインスタンスフォルダーから削除します。
2.5.2.4.1.7. トークンアクティビティーログ
特定の TPS アクティビティーがログに記録されます。ログファイル内の考えられるイベントは、以下の表にリスト表示されています。

表2.13 TPS アクティビティーログイベント

アクティビティー 説明
add トークンが追加されました。
format トークンがフォーマットされました。
enrollment トークンが登録されました。
recovery トークンが復元されました。
更新 トークンが更新されています。
pin_reset トークンの PIN がリセットされました。
token_status_change トークンステータスは、コマンドラインまたはグラフィカルインターフェイスを使用して変更されました。
token_modify トークンが変更されました。
delete トークンが削除されました。
cert_revocation トークン証明書が取り消されました。
cert_unrevocation トークン証明書は失効しませんでした。
2.5.2.4.2. トークンポリシー
内部登録の場合、各トークンをトークンポリシーのセットで制御できます。デフォルトのポリシーは以下のとおりです。
RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO;RENEW_KEEP_OLD_ENC_CERTS=YES
内部登録中の TPS 操作は、トークンの記録に指定したポリシーの対象です。トークンにポリシーが指定されていない場合、TPS はデフォルトのポリシーセットを使用します。

2.5.2.5. マッピングリゾルバー

Mapping Resolver は、設定可能な基準に基づいて特定のトークンに割り当てるトークンプロファイルを決定するために TPS が使用する拡張可能なメカニズムです。各マッピングリゾルバーインスタンスは設定で一意に定義でき、各操作は定義されたマッピングリゾルバーインスタンスを参照できます。
注記
マッピングリゾルバーフレームワークは、カスタムプラグインを作成するプラットフォームを提供します。ただし、プラグインの作成方法に関する説明は、本書の範囲外です。
FilterMappingResolver は、デフォルトで TPS で提供される唯一のマッピングリゾルバー実装です。これにより、各マッピングに マッピング のセットおよびターゲットの結果を定義できます。各マッピングにはフィルターのセットが含まれ、ここでは以下のようになります。
  • 入力フィルターパラメーターがマッピング内の すべて のフィルターを渡すと、target の値が割り当てられます。
  • 入力パラメーターでフィルターが失敗すると、そのマッピングはスキップされ、次の順番に試行されます。
  • フィルターに指定された値がない場合は、常に合格します。
  • フィルターに指定された値がある場合、入力パラメーターは完全に一致する必要があります。
  • マッピングが定義される順序は重要です。合格した最初のマッピングは解決されたと見なされ、呼び出し元に返されます。
入力フィルターパラメーターは、拡張の有無にかかわらずスマートカードトークンから受け取った情報です。上記のルールに従って、FilterMappingResolver に対して実行されます。FilterMappingResolver では、以下の入力フィルターパラメーターがサポートされます。
  • appletMajorVersion - トークン上の Coolkey アプレットのメジャーバージョン。
  • appletMinorVersion - トークン上の Coolkey アプレットのマイナーバージョン。
  • keySet または tokenType
    • keySet - クライアントリクエストでエクステンションとして設定できます。拡張子が指定されている場合は、フィルターの値と一致する必要があります。keySet マッピングリゾルバーは、外部登録を使用する際に keySet 値を決定することを目的としています。複数の鍵セットがサポートされる場合は、外部登録環境で Key Set Mapping Resolver が必要になります (たとえば、スマートカードトークンベンダーごとに必要です)。keySet 値は、Secure Channel を確立する上で重要な TKS のマスターキーを特定するために必要です。ユーザーの LDAP レコードにセット tokenType (TPS プロファイル) が入力されている場合は、どのカードが最終的に登録を行うかがわからないため、keySet を事前に決定することはできません。keySetMappingResolver は、認証前に keySet が解決できるようにすることで、問題の解決に役立ちます。
    • tokenType - okenType は、クライアントリクエストの拡張機能として設定できます。拡張子が指定されている場合は、フィルターの値と一致する必要があります。tokenType (TPS プロファイルとも呼ばれます) は、この時点で内部登録環境に対して決定されます。
  • tokenATR - トークンの Answer to Reset (ATR) です。
  • tokenCUID - start および end は、このフィルターに渡すためにトークンの Card Unique ID (CUID) の範囲を定義します。

2.5.2.6. TPS ロール

TPS は、デフォルトで以下のロールをサポートします。
  • TPS 管理者: このロールは以下を許可します。
    • TPS トークンの管理
    • TPS 証明書およびアクティビティーの表示
    • TPS ユーザーおよびグループの管理
    • 一般的な TPS 設定の変更
    • TPS オーセンティケーターおよびコネクターの管理
    • TPS プロファイルおよびプロファイルマッピングの設定
    • TPS 監査ロギングの設定
  • TPS エージェント: このロールは以下を許可します。
    • TPS トークンの設定
    • TPS 証明書およびアクティビティーの表示
    • TPS プロファイルのステータスの変更
  • TPS オペレーター: このロールは以下を許可します。
    • TPS トークン、証明書、およびアクティビティーの表示

2.5.3. TKS/TPS 共有シークレット

TMS のインストール時に、トークンキーサービスとトークン処理システム間に共有された対称鍵が確立されます。この鍵の目的は、Secure Channel に不可欠であるセッションキーをラップしてアンラップすることです。
注記
現在、共有秘密鍵は、ソフトウェア暗号化データベースにのみ保持されます。Red Hat Certificate System の将来のリリースでは、ハードウェアセキュリティーモジュール (HSM) デバイスでのキーの保持をサポートする計画があります。この機能が実装されたら、キーを HSM に転送するように tkstool を使用して Key Ceremony を実行するように指示します。

2.5.4. Enterprise Security Client (ESC)

Enterprise Security Client は、TPS と通信し、クライアント側からスマートカードトークンを処理する Web ブラウザーと同様に HTTP クライアントアプリケーションです。ESC と TPS の間で HTTPS 接続が確立されている間、各 TLS セッション内のトークンと TMS の間でも基盤となる Secure Channel が確立されます。