This article includes updates for Smart ID 23.04.9 and 23.10.3.

Only cards based on the common IN Groupe profile are supported.

Some operations require one or more keysets to be defined to enable external authentication. 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.

In addition, a chip auth key config needs to be defined for all use-cases that require a secure channel. It consists of a key path and a key ID.

The following values are used in the example below:

Chip auth key config:

Do the following:

• Define the keyset configuration. 

  Code Block
  title Example: Keyset configuration
  [Description] ... KeysetSkAdmin=#theKeyLabel1:theKeyPath1 KeysetSkUnblkPin=#theKeyLabel2:theKeyPath2 KeysetSkFileMgmt=#theKeyLabel3:theKeyPath3 ChipAuthKeyConfig=#theKeyPath4:theKeyId4

  You can also use mapped fields:

  Code Block
  title Example: Keyset configuration - mapped field
  [Fields] KEYSET_ADMIN= [Description] ... KeysetSkAdmin=KEYSET_ADMIN

  
  

Overwiew of which keyset and chip auth parameters to configure, depending on the use-case:

	KeysetSkAdmin	KeysetSkUnblkPin	KeysetSkFileMgmt	ChipAuthkeyConfig
ICCSN reading
Card initialization (activation)
Card deactivation	TBD			TBD
Keypair generation
Key import (key archival/recovery)
Certificate writing
Cert+key deletion
PIN change (via old PIN)		(must be absent!)
Unblock PIN (via PUK)		(must be absent!)
Unblock PIN (via SK_UNBLK)
EF data objects reading
EF data objects writing

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

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.

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

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

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

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

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

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

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

The current card profile supports two "containers" in which to store certificates: sign (guarded by the signature PIN) and mpp (guarded by the global PIN).

It is mandatory that you specify the location for each certificate you want to write. Valid location values are (case insensitive) Signature and MPP. Key archival or recovery is only possible with the MPP location.

For key archival you have to configure the key size either in the CA itself or via the KeySize parameter of the IDM certificate template, depending on the CA and its configuration.
For example, in Smart ID Certificate Manager you need to use a key procedure format with kar.key.type = RSA and keylength.value = 3072 in your archival procedure.

For key recovery you cannot specify the key size, as it is already pre-defined by the key to be recovered.

For PKCS#10 requests you have to set the correct key size via the KeySize parameter in the encoding description, as shown in the encoding example further below.

	mpp	sign
Location parameter value  (mandatory!)	"MPP"	"signature"
Associated PIN type	global ("PIN=...")	signature ("SignPIN=...")
Keypair generation + PKCS#10 request
Keypair import (key archival / recovery)
Maximum number of 2048 bit RSA certificates/keys	1	0
Maximum number of 3072 bit RSA certificates/keys	5	2

Three new certificates are requested in the example below: authentication, signature, and confidentiality (using key archival for the latter).

 The service task "Cert: Load Key History List" must be configured to recover just one single cert, otherwise the limit of allowed certificates can be exceeded. For more information, see section "Cert: Load Key History List" in Standard service tasks in Identity Manager.

• Define the request for multiple certificates in the encoding description.
  

Smart ID Identity Manager supports reading the EF.Id (Card Holder Identification) and EF.Fonction (Professional information) data containers.

Do the following in the encoding description:

1. In the [Description] section, set readDataObjects to "true".
2. In the [Description] section, provide the file management keyset.
3. In the [Fields] section, add the keys of the data you want to read.
   • The keys for the EF.Fonction container are ef.function.job, ef.function.postingPlace and ef.function.productionDate.
   • The keys for the EF.Id container are ef.id.familyName, ef.id.firstName, ef.id.rio, ef.id.uin, ef.id.orgName1 and ef.id.orgName2.
4. In the Encoding Fields tab, set the added fields to "Read" and map them to a process variable.

Smart ID Identity Manager supports updating the EF.Id (Card Holder Identification) and EF.Fonction (Professional information) data containers.

Do the following in the encoding description:

1. In the [Description] section, provide the file management keyset.
2. In the [Description] section, set the keys of the data you want to update and map them to a field. Any keys you omit will keep their old value.
   • The keys for the EF.Fonction container are ef.function.job, ef.function.postingPlace and ef.function.productionDate.
   • The keys for the EF.Id container are ef.id.familyName, ef.id.firstName, ef.id.rio, ef.id.uin, ef.id.orgName1 and ef.id.orgName2.
3. In the [Fields] section, define the fields you referenced in the previous step.
4. In the Encoding Fields tab, set the value of the fields. To clear a field in a data container, map it to an empty value.

Creating certificates and keys on JCOP 4.5 cards requires card firmware with support for chained APDUs when used with certain pinpad readers (e.g. Xiring / Ingenico Leo series).
For those readers the cards need to have version 4.1.1 of the Chipdoc applet.

Pre-release cards produced before 2023-10-12 are not supported due to a flaw in the card profile fixed in later revisions.
It would prevent proper authentication for write access to EF data containers.