6.4. トークン操作およびポリシー処理
このセクションでは、トークンに関連する主要な操作 (明示的および暗黙的) を説明します。以下のリストは、各機能とその設定について記載しています。
注記
一般情報は、『Red Hat Certificate System 計画、インストール、デプロイメントのガイド』 の 『トークンポリシー』 セクションを参照してください。
- 形式
- (ユーザーが開始した) Format 操作は、製造元から提供された完全に空白の状態のトークンを受け取り、Coolkey アプレットを読み込みます。設定例:
#specify that we want authentication for format. We almost always want this at true: op.format.userKey.auth.enable=true #specify the ldap authentication configuration, so TPS knows where to validate credentials: op.format.userKey.auth.id=ldap1 #specify the connection the the CA op.format.userKey.ca.conn=ca1 #specify id of the card manager applet on given token op.format.userKey.cardmgr_instance=A0000000030000 #specify if we need to match the visa cuid to the nist sp800sp derivation algorithm KDD value. Mostly will be false: op.format.userKey.cuidMustMatchKDD=false #enable ability to restrict key changoever to a specific range of key set: op.format.userKey.enableBoundedGPKeyVersion=true #enable the phone home url to write to the token: op.format.userKey.issuerinfo.enable=true #actual home url to write to token: op.format.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome #specify whether to request a login from the client. Mostly true, external reg may want this to be false: op.format.userKey.loginRequest.enable=true #Actual range of desired keyset numbers: op.format.userKey.maximumGPKeyVersion=FF op.format.userKey.minimumGPKeyVersion=01 #Whether or not to revoke certs on the token after a format, and what the reason will be if so: op.format.userKey.revokeCert=true op.format.userKey.revokeCert.reason=0 #This will roll back the reflected keyyset version of the token in the tokendb. After a failed key changeover operation. This is to keep the value in sync with reality in the tokendb. Always false, since this version of TPS avoids this situation now: op.format.userKey.rollbackKeyVersionOnPutKeyFailure=false #specify connection to the TKS: op.format.userKey.tks.conn=tks1 #where to get the actual applet file to write to the token: op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets #Allows a completely blank token to be recognized by TPS. Mostly should be true: op.format.userKey.update.applet.emptyToken.enable=true #Always should be true, not supported: op.format.userKey.update.applet.encryption=true #Actual version of the applet file we want to upgrade to. This file will have a name something like: 1.4.54de7a99.ijc: op.format.userKey.update.applet.requiredVersion=1.4.54de790f #Symm key changeover: op.format.userKey.update.symmetricKeys.enable=false op.format.userKey.update.symmetricKeys.requiredVersion=1 #Make sure the token db is in sync with reality. Should always be true: op.format.userKey.validateCardKeyInfoAgainstTokenDB=true
- 登録
- 基本的な登録操作では、フォーマットされたトークンを取得し、トークンをカスタマイズするために証明書とキーをトークンに配置します。次の設定例では、これを制御する方法を説明します。この例は、更新および内部リカバリーを処理しない基本的な登録を示しています。ここで説明されていない設定は、Format セクションで説明されています。または必須ではありません。
op.enroll.userKey.auth.enable=true op.enroll.userKey.auth.id=ldap1 op.enroll.userKey.cardmgr_instance=A0000000030000 op.enroll.userKey.cuidMustMatchKDD=false op.enroll.userKey.enableBoundedGPKeyVersion=true op.enroll.userKey.issuerinfo.enable=true op.enroll.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome #configure the encryption cert and keys we want on the token: #connection the the CA, which issues the certs: op.enroll.userKey.keyGen.encryption.ca.conn=ca1 #Profile id we want the CA to use to issue our encrytion cert: op.enroll.userKey.keyGen.encryption.ca.profileId=caTokenUserEncryptionKeyEnrollment #These two cover the indexes of the certs written to the token. Each cert needs a unique index or “slot”. In our sample the enc cert will occupy slot 2 and the signing cert, shown later, will occupy slot 1. Avoid overlap with these numbers: op.enroll.userKey.keyGen.encryption.certAttrId=c2 op.enroll.userKey.keyGen.encryption.certId=C2 op.enroll.userKey.keyGen.encryption.cuid_label=$cuid$ #specify size of generated private key: op.enroll.userKey.keyGen.encryption.keySize=1024 op.enroll.userKey.keyGen.encryption.keyUsage=0 op.enroll.userKey.keyGen.encryption.keyUser=0 #specify pattern for what the label of the cert will look like when the cert nickname is displayed in browsers and mail clients: op.enroll.userKey.keyGen.encryption.label=encryption key for $userid$ #specify if we want to overwrite certs on a re-enrollment operation. This is almost always the case: op.enroll.userKey.keyGen.encryption.overwrite=true #The next several settings specify the capabilities that the private key on the final token will inherit. For instance this will determine if the cert can be used for encryption or digital signatures. There are settings for both the private and public key. op.enroll.userKey.keyGen.encryption.private.keyCapabilities.decrypt=true op.enroll.userKey.keyGen.encryption.private.keyCapabilities.derive=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.encrypt=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.private=true op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sensitive=true op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sign=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.signRecover=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.token=true op.enroll.userKey.keyGen.encryption.private.keyCapabilities.unwrap=true op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verify=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verifyRecover=false op.enroll.userKey.keyGen.encryption.private.keyCapabilities.wrap=false op.enroll.userKey.keyGen.encryption.privateKeyAttrId=k4 op.enroll.userKey.keyGen.encryption.privateKeyNumber=4 op.enroll.userKey.keyGen.encryption.public.keyCapabilities.decrypt=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.derive=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.encrypt=true op.enroll.userKey.keyGen.encryption.public.keyCapabilities.private=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sensitive=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sign=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.signRecover=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.token=true op.enroll.userKey.keyGen.encryption.public.keyCapabilities.unwrap=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verify=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verifyRecover=false op.enroll.userKey.keyGen.encryption.public.keyCapabilities.wrap=true #The following index numbers correspond to the index or slot that the private and public keys occupy. The common formula we use is that the public key index will be 2 * cert id + 1, and the private key index, shown above will be 2 * cert id. In this example the cert id is 2, so the key ids will be 4 and 5 respectively. When composing these, be careful not to create conflicts. This applies to the signing key section below. op.enroll.userKey.keyGen.encryption.publicKeyAttrId=k5 op.enroll.userKey.keyGen.encryption.publicKeyNumber=5 #specify if, when a certificate is slated for revocation, based on other rules, we want to check to see if some other token is using this cert in a shared situation. If this is set to true, and this situation is found the cert will not be revoked until the last token wants to revoke this cert: op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false #specify, if we want server side keygen, if we want to have that generated key archived to the drm. This is almost always the case, since we want the ability to later recover a cert and its encryption private key back to a new token: op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true #connection to drm to generate the key for us: op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1 #specify server side keygen of the encryption private key. This most often will be desired: op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true #This setting tells us how many certs we want to enroll for this TPS profile, in the case “userKey”. Here we want 2 total certs. The next values then go on to index into the config what two types of certs we want, signing and encryption: op.enroll.userKey.keyGen.keyType.num=2 op.enroll.userKey.keyGen.keyType.value.0=signing op.enroll.userKey.keyGen.keyType.value.1=encryption #configure the signing cert and keys we want on the token the settings for these are similar to the encryption settings already discussed, except the capability flags presented below, since this is a signing key. op.enroll.userKey.keyGen.signing.ca.conn=ca1 op.enroll.userKey.keyGen.signing.ca.profileId=caTokenUserSigningKeyEnrollment op.enroll.userKey.keyGen.signing.certAttrId=c1 op.enroll.userKey.keyGen.signing.certId=C1 op.enroll.userKey.keyGen.signing.cuid_label=$cuid$ op.enroll.userKey.keyGen.signing.keySize=1024 op.enroll.userKey.keyGen.signing.keyUsage=0 op.enroll.userKey.keyGen.signing.keyUser=0 op.enroll.userKey.keyGen.signing.label=signing key for $userid$ op.enroll.userKey.keyGen.signing.overwrite=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.decrypt=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.derive=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.encrypt=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.private=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.sensitive=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.sign=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.signRecover=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.token=true op.enroll.userKey.keyGen.signing.private.keyCapabilities.unwrap=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.verify=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.verifyRecover=false op.enroll.userKey.keyGen.signing.private.keyCapabilities.wrap=false op.enroll.userKey.keyGen.signing.privateKeyAttrId=k2 op.enroll.userKey.keyGen.signing.privateKeyNumber=2 op.enroll.userKey.keyGen.signing.public.keyCapabilities.decrypt=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.derive=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.encrypt=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.private=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.sensitive=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.sign=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.signRecover=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.token=true op.enroll.userKey.keyGen.signing.public.keyCapabilities.unwrap=false op.enroll.userKey.keyGen.signing.public.keyCapabilities.verify=true op.enroll.userKey.keyGen.signing.public.keyCapabilities.verifyRecover=true op.enroll.userKey.keyGen.signing.public.keyCapabilities.wrap=false op.enroll.userKey.keyGen.signing.publicKeyAttrId=k3 op.enroll.userKey.keyGen.signing.publicKeyNumber=3
- ピンリセット
- ピンリセットは、合理的に実行されるべきかどうかを判断するポリシーに依存するため、ピンリセットの設定については 「トークンポリシー」 で説明しています。
- 更新
- 更新は、すでに登録されているトークンに対して実行することが合法であるかどうかを判断するためのポリシーに依存しているため、更新の設定については 「トークンポリシー」 で説明しています。
- 復元
- TPS ユーザーインターフェイスのユーザーが以前にアクティブだったトークンを “紛失” や “破棄” などの好ましくない状態にマークすると、復元が暗黙的に開始されます。これが発生すると、同じユーザーによる次の新しいトークンの登録は、次の設定に従って、ユーザーの古いトークンからこの新しいトークンに証明書を復元します。この操作の最終結果は、ユーザーが古いトークンから回復された暗号化証明書を含む可能性のある新しい物理トークンを取得することです。これにより、ユーザーは必要に応じてデータの暗号化と復号を続行できます。以下のサンプル設定例に示すように、通常、新しい署名証明書もこのトークンに配置されます。以下は、設定に示されているように、TPS ユーザーインターフェイスでトークンを手動で配置できるサポートされている状態のリストです。
tokendb._069=#-DAMAGED (1): リカバリー設定のdestroyedに相当します。トークンが物理的に破損された場合に使用します。tokendb._070=#-PERM_LOST (2): リカバリー設定のkeyCompromiseに相当します。トークンが永久に失われた場合に使用されます。tokendb._071=#-SUSPENDED (3): リカバリー設定のonHoldに相当します。トークンを一時的に配置した際に使用されますが、ユーザーはトークンを再度検索することが予想されます。tokendb._072=#-TERMINATED (6): リカバリー設定でterminatedするもの。トークンをサービス対象外にするために内部の理由から使用します。
リカバリー設定の例:#When a token is marked destroyed, don’t revoke the certs on the token unless all other tokens do not have the certs included: op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false #specify if we even want to revoke certs a token is marked destroyed: op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert=false #if we want to revoke any certs here, specify the reason for revocation that will be sent to the CA: op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert.reason=0 #speficy if we want to revoke expired certs when marking the token destroyed: op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeExpiredCerts=false
追加の設定を使用して、新しいトークンに対して回復操作を実行するときに (元のトークンが破棄済みとしてマークされている場合)、サポートされている静的回復の種類を指定します。以下のスキームがサポートされます。- Recover Last (
RecoverLast): トークンに配置される最新の暗号化証明書を復旧します。 - Generate New Key and Recover Last (
GenerateNewKeyAndRecoverLast): Recover Last と同じですが、新しい暗号化証明書を生成し、トークンにアップロードします。新しいトークンには 2 つの証明書が含まれます。 - Generate New Key (
GenerateNewKey): 新しい暗号化証明書を生成し、トークンに配置します。古い証明書は復元しないでください。
以下に例を示します。op.enroll.userKey.keyGen.encryption.recovery.destroyed.scheme=RecoverLast
次の設定例は、永久に失われたとマークされたトークンを回復する方法を決定します。op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1 op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeExpiredCerts=false op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.scheme=GenerateNewKey # Section when a token is marked terminated. op.enroll.userKey.keyGen.encryption.recovery.terminated.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert=true op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert.reason=1 op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeExpiredCerts=false op.enroll.userKey.keyGen.encryption.recovery.terminated.scheme=GenerateNewKey # This section details the recovery profile with respect to which certs and of what kind get recovered on the token. op.enroll.userKey.keyGen.recovery.destroyed.keyType.num=2 op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.0=signing op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.1=encryption
最後に、次の例では、古いトークンにあった署名証明書に対してシステムが何を行うかを決定します。ほとんどの場合、署名秘密鍵の複数のコピーが使用可能になる可能性を回避するために、GenerateNewKey復元スキームを使用する必要があります (たとえば、新しいトークンで復元されたものと、永久に失われたが他の誰かによって発見された古いトークンで復元されたもの)。op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.0=signing op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.1=encryption op.enroll.userKey.keyGen.recovery.onHold.keyType.num=2 op.enroll.userKey.keyGen.recovery.onHold.keyType.value.0=signing op.enroll.userKey.keyGen.recovery.onHold.keyType.value.1=encryption op.enroll.userKey.keyGen.signing.recovery.destroyed.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert.reason=0 op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeExpiredCerts=false op.enroll.userKey.keyGen.signing.recovery.destroyed.scheme=GenerateNewKey op.enroll.userKey.keyGen.signing.recovery.keyCompromise.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert.reason=1 op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeExpiredCerts=false op.enroll.userKey.keyGen.signing.recovery.keyCompromise.scheme=GenerateNewKey op.enroll.userKey.keyGen.signing.recovery.onHold.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert.reason=6 op.enroll.userKey.keyGen.signing.recovery.onHold.revokeExpiredCerts=false op.enroll.userKey.keyGen.signing.recovery.onHold.scheme=GenerateNewKey op.enroll.userKey.keyGen.signing.recovery.terminated.holdRevocationUntilLastCredential=false op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert=true op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert.reason=1 op.enroll.userKey.keyGen.signing.recovery.terminated.revokeExpiredCerts=false op.enroll.userKey.keyGen.signing.recovery.terminated.scheme=GenerateNewKey # Configuration for the case when we mark a token “onHold” or temporarily lost op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert=true op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert.reason=0 op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.scheme=RecoverLast op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.num=2 op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.0=signing op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.1=encryption op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert=true op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert.reason=0 op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.scheme=GenerateNewKey
- アプレットの更新
- 以下の例は、Coolkey アプレット更新操作の設定方法を示しています。この操作は、フォーマット、登録、および PIN のリセット操作中に実行できます。
op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets op.format.userKey.update.applet.emptyToken.enable=true op.format.userKey.update.applet.encryption=true op.format.userKey.update.applet.requiredVersion=1.4.54de790f
これらのオプションの一部は、Format セクションですでに紹介されています。これらは、アプレットのアップグレードを許可する必要があるかどうか、アプレットファイルの場所、およびトークンをアップグレードするアプレットのバージョンを決定するために必要な情報を提供します。requiredVersionのバージョンは、directory内のファイル名にマッピングされます。 - キーの更新
- この操作は、フォーマット、登録、および PIN リセット操作中に実行でき、ユーザーは Global Platform キーセットのバージョンを製造元が提供するデフォルトからアップグレードできます。
- TPS
- 次のオプションは、特定のトークンに代わって要求された次のフォーマット操作中に、キーセットを 1 から 2 にアップグレードするように TPS に指示します。これが行われたら、TKS はトークンに書き込まれる 3 つの新しいキーを取得する必要があります。その後、トークンは同じ TPS および TKS インストールで使用する必要があります。そうしないと、ロックされます。
op.format.userKey.update.symmetricKeys.enable=true op.format.userKey.update.symmetricKeys.requiredVersion=2
代わりに、現在よりも低いバージョンを指定して、キーセットをダウングレードすることもできます。 - TKS
- 上記のように、TKS は、トークンに書き込む新しい鍵を生成するように設定する必要があります。まず、新しいマスターキー識別子
02は、次の例に示すように、TKSCS.cfgの PKCS #11 オブジェクトのニックネームにマップする必要があります。tks.mk_mappings.#02#01=internal:new_master tks.defKeySet.mk_mappings.#02#01=internal:new_master
上記の例では、キーセット番号が TKS NSS データベースに存在する実際のマスターキーにマップされます。マスターキーは、01などの ID で識別されます。TKS は、この ID を、マッピングのmasterKeyId部分として指定した PKCS #11 オブジェクトのニックネームにマッピングします。したがって、最初の番号はマスターキーのバージョンが更新されると更新され、2 番目の番号は一貫性を保ちます。バージョン 1 からバージョン 2 にアップグレードしようとすると、マッピングによって、新しいキーセットの 3 つの部分を取得するために使用されるマスターキーのニックネームを見つける方法が決まります。上記の例internalの設定は、マスターキーがあるトークンの名前を参照します。また、nethsmなど、名前を持つ外部 HSM モジュールも使用できます。強力なnew_masterは、マスターキーのニックネーム自体の例です。
