JCOP 3 PGCA cards with Idopte middleware

This article includes updates for Smart ID 23.10.16.

This article contains details specific to the use of JCOP 3 cards using the PGCA profile with the Idopte Middleware.
See JCOP 3 MI cards with Idopte middleware for MI cards, instead of this document.

Customer-specific variations of the PGCA profile may exist, which are not yet supported.

Pre-loaded Factory Certificates

The cards are provided with certain keypairs and certificates from the factory, most notably these:

• 1x signature (label: “sign”)

• 1x authentication (label: “auth”)

• 1x confidentiality/encryption (label: “cyph”)

The cards need to be activated (see “Card Initialization” below) for those certificates and keys to be properly exposed in the PKCS#15 file structure.

Certificate container selection

Define target certificate container

The current card profile supports up to two signature certificates, protected by a dedicated signature PIN.

Two authentication certificates and three confidentiality certificates can also be written onto the card, protected by the normal PIN.

To select the container, you need to specify the location (the authentication container is chosen otherwise).
Valid location values are (case insensitive) Signature and Confidentiality. Key archival or recovery is only possible with the Confidentiality location.

The MPP (“multi-purpose”) container on these cards is unsupported by IDM.
Any objects in there will be ignored by IDM (not even logged), and attempting to write to the “mpp” location will result in an error.

• Define the container location in the encoding description:

  CODE

  [Application_X]
  location=#Signature
  ...

Keyset configuration

Configure keysets

Some operations require one or more keysets to be defined to enable external authentication and secure channel establishment. Each keyset configuration consists of a key label in an HSM (for example connected to the Inside Server), and in most cases a key path indicating a matching key on the card.

The following values are used in the example below:

Do the following:

• Define the keyset configuration:

  CODE

  [Description]
  ...
  KeysetADMIN=#theKeyLabel1:theKeyPath1
  KeysetUNBLK_G=#theKeyLabel2:theKeyPath2
  KeysetUNBLK_S=#theKeyLabel3:theKeyPath3

  You can also use mapped fields:

  CODE

  [Fields]
  KEYSET_ADMIN=
   
  [Description]
  ...
  KeysetADMIN=KEYSET_ADMIN

Configuration overview

Overview of which keyset parameters to configure, depending on the use-case:

Card initialization

Card initialization steps for explanation only (not executed by the user)

• External authentication with the ADMIN keyset.

• Login with transport PIN (parameter "IdopteTransportPin=..."). For information about decrypting the transport PIN, see section "Credentials: Decrypt fields using Inside Server" in Credentials - Standard service tasks in Identity Manager. 

• Mutual authentication with the ADMIN keyset.

• Initialization of global PIN (parameter "PIN=...") and signature PIN (parameter "SignPIN=...").

• Unblocking the single-use PUKs for global/signature PINs as these are already present on the card (to match existing cards using the same profile).

• Activating the “auth” container, which will expose all of the pre-loaded certificates.

• External authentication with an ADMIN keyset.

• Blocking the transport PIN.

Cards using the PGCA profile contain certain pre-loaded certificates and keypairs (one for signature / authentication / confidentiality each).

Those are exposed on in PKCS#15 by activating the “auth” container, which also activates all certificate slots except for the second “sign” slot.

Keyset parameter required: KeysetADMIN.

Each of the three PINs (transport/global/signature) must come from a mapped field, so they need to be entered in a user-task form of the process.
Using a PIN dialog is not supported for card initialization.

The step below may be run only once, attempting to initialize an already initialized ("activated") card will result in an error.

• Define the initialization of the card in the encoding description (executed by the user).

Example: Card initialization

[Fields]
TRANSPORT_PIN=
GLOBAL_PIN=
SIGNATURE_PIN=

[Description]
...
InitToken=true
KeysetADMIN=...
 
PIN=GLOBAL_PIN
SignPIN=SIGNATURE_PIN
IdopteTransportPin=TRANSPORT_PIN

Both the global PIN and the signature PIN each have three single-use PUKs assigned to them, which can be used for PIN unblocking.
Identity Manager does not support these PUKs, the UNBLK_G and UNBLK_S keysets is used instead to enable unblocking.

Change and unblock PIN

Change signature/global PIN

You can change the global and/or signature PIN with the user entering the old and new PIN(s) in a dialog or through a PIN pad reader.

No keyset parameters are required. Do not set KeysetUNBLK_G, if changing global PIN and do not set KeysetUNBLK_S if changing signature PIN.

• Change the signature/global PIN in the encoding description. 

Example: Signature PIN change (via PIN dialog)

[Description]
...
SetPin=true
SignPIN=!FROM_USER_DIALOG_3_FIELD

Unblock signature/global PIN

You can unblock the global and/or signature PIN, with the user entering the new PIN(s) in a dialog.

Required keyset parameter: KeysetUNBLK_G, (for global PIN) or KeysetUNBLK_S (for signature PIN).

• Unblock the global/signature PIN in the encoding description. 

Example: Signature PIN unblocking

[Description]
...
SetPin=true
SignPin=!FROM_USER_DIALOG_2_FIELD
KeysetUNBLK_S=...

Example: Global PIN unblocking

[Description]
...
SetPin=true
Pin=!FROM_USER_DIALOG_2_FIELD
KeysetUNBLK_G=...

Delete certificates and keys

Delete certificates and RSA keys from card

You can bulk-delete all existing certificates and RSA keys from the card. Selective deletion of individual certificates and keys is not supported.

Required keyset parameters: KeysetAD and KeysetADMIN.

• Delete all existing certificates and RSA keys from the card in the encoding description. 

Example: Delete all keys and certificates (from card)

[Description]
...
KeysetAD=...
KeysetADMIN=...
ApplicationList=X
 
[Application_X]
DeleteAllObjects=true

Certificate requests

Request certificates

The card profile supports storage of up to six certificates and associated 2048 bit RSA keypairs organized into four "containers".

"conf" (confidentiality) refers to encryption certificates (for example for S/MIME).

Required keyset parameter: KeysetADMIN.

You must always disable certificate chain writing ("StoreUserCertOnly=true") since the card profile does not allow for storage of CA certificates.

You need to provide the PIN=… and/or SignPIN=… options, so PKCS#10 requests for authentication and signature certificates can be signed with the generated private key.

The following example shows renewal plus recovery, retaining the factory-created confidentiality certificate, but removing the factory-created authentication and signature certificates.

For key archival of a historical confidentiality certificate the service task "Cert: Load Key History List" must be configured to recover only a single certificate, otherwise the limit of allowed certificates will be exceeded. For more information, see section "Cert: Load Key History List" in Standard service tasks in Identity Manager.

Example: Renewal plus recovery of historic encryption certificate

[Encoding]
Type=1024,Chip
Devices=8711

[Fields]
P12PASSWORD_C=
P12PASSWORD_R=
RecoveryCertificateData_R=
ICCSN=

[Description]
PKCS11Library=idopte
# TODO: define admin keyset here
KeysetAdmin=...

# P10 signing for auth/sign certs requires login with respective PIN
PIN=!FROM_USER_DIALOG_1_FIELD
SignPIN=!FROM_USER_DIALOG_1_FIELD

# selection of the card by ICCSN is recommended for security reasons,
# the field "ICCSN" must be filled from the process map with the target ICCSN of the correct card
UseSelectCriteriaIccsn=true
SelectCriteriaICCSN=ICCSN

ApplicationList=ABCRX

# keypair gen + cert request of new signature certificate
[Application_A]
CertTempl=MySigCertTemplate
StoreUserCertOnly=true
Location=#signature
LabelTemplate=fixtext=signRenewal

# keypair gen + cert request of new auth certificate
[Application_B]
CertTempl=MyAuthCertTemplate
StoreUserCertOnly=true
# auth certs use default Location
LabelTemplate=fixtext=authRenewal

# key archival for new encryption/confidentiality certificate
[Application_C]
P12PASSWORD=P12PASSWORD_C
CertTempl=MyEncCertTemplate
KeyArchivalRequest=true
StoreUserCertOnly=true
location=#confidentiality
LabelTemplate=fixtext=cyphRenewal
        
# key recovery of historic encryption/confidentiality certificate
[Application_R]
CertTempl=Recovery
RecoveryTemplate=Recovery
KeyRecoveryRequest=true
P12PASSWORD=P12PASSWORD_R
RecoveryCertificateData=RecoveryCertificateData_R
StoreUserCertOnly=true
Location=#confidentiality
LabelTemplate=fixtext=cyphRecovery

# delete factory-created sign+auth certificates and keys
[Application_X]
DeleteCertKeyObjects=true
DeleteCertKeyObjectsCriteria=Label(sign,auth)

Idopte middleware limitations

Serial number reading

When reading the ICCSN, the full value serial from EF.SN (without tag and length bytes) is returned.

The last digit is not displayed anywhere in the Idopte middleware.

Example

This is an example for a card which is shown in the Idopte middleware user interface as follows:
Card model: IAS ECC 9-250-03
Serial number: 2702338220012

EF.SN raw bytes (includes tag and length):                5A0A92500327023382200127
Full serial, i.e. EF.SN without tag and length bytes:         92500327023382200127  <=== this is returned
Shown in the Idopte UI:                                       9250032702338220012
Portion shown in the card model section:                      925003
Portion shown in the serial number section:                         2702338220012

Further Limitations

No pinpad support

Pinpad readers cannot be used for cards using the PGCA profile.

Empty ManufacturerID

When reading the token info JSON on cards using the PGCA the manufacturerID field is empty.

Additional information