Follow instructions in this article which will explain the settings that can be configured from this section.
From the Smart Cards page, it is possible to configure the default administration key values, as set by the smart card manufacturer, to a configurable value.
If the smart card minidriver is not installed on the system that the vSEC:CMS is running on then the smart card will not be recognized and consequently it will not be possible to perform operations with the smart card.
To add a new smart card type, attach the smart card you wish to add and click the Add button. Enter a template name and click the Add button.
If the ATR is unknown click the Get button to automatically retrieve the ATR.
In this section, the expected administration key value when the smart card is received from the vendor can be set here along with the default administration value that will be set on the smart card when it is unregistered by the vSEC:CMS application. The key type can also be configured.
The ATR and some parts of the bytes are unique for a specific card type, whereas other smart cards may differ. Even so, the card type is still the same.
For example, the Gemalto .NET smart cards can have ATR=3B0000417374726964, or ATR=3B0001417374726964.
From this, a mask can be configured to inform an application using the smart card which part of the ATR to compare. In the example given, Mask=FF0000FFFFFFFFFFFF means that the bytes 3B and 417374726964 will have to be identical, while the bytes 0000 can be different.
If you are managing a Gemalto/Safenet eToken it will be necessary to have the Safenet Authentication Client (SAC) installed on the host where you manage the tokens from. Additionally, if you require that the vSEC:CMS should perform the initialization of the token then from the smart card dialog enable the Initialize the token at registration check box. This will remove the requirement to initialize these tokens using SAC which would be required if you did not wish for the vSEC:CMS to perform this task.
If you are managing Atos CardOS smart cards it will be necessary to have them initialized firstly using the CardOS API application using a PUC code of 123456.
Secure messaging provides end-to-end security for the communication between the smart card and off-card entity, the vSEC:CMS in this case, by adding confidentiality, integrity and authentication to the APDU transactions for the smart card. This feature is supported for the PIV cards supported by the vSEC:CMS.
In order to use this feature, it will be necessary to configure the keys used to establish the secure channel for the secure messaging. Key usage here is implemented based on the global platform specification.
From the Options - Smart Cards page select the PIV card and click the SM Key(s) button to configure secure messaging keys.
Depending on the card type used the vSEC:CMS uses the default factory keys used for establishing secure messaging channel. If these values are not the default value then it will be necessary to change the values here. Please consult with your provider if the keys are not the default values. The keys configured here are based on the global platform specification.
The vSEC:CMS can take ownership of managing the GP. This means that if the checkbox Take ownership when managing the smart card is enable then you can select the Static key or Diversified key option. If Static key option is selected then the value entered in the field provided will be set on any card that is registered and managed by the vSEC:CMS. When the card is unregistered the vSEC:CMS will set the GP keys back to the default values as set in ROOT, ENC, MAC and DEK. Similarly, if Diversified key option is selected the vSEC:CMS will diversify a new GP key for any card registered and managed by the vSEC:CMS. Again, in this case when the card is unregistered the vSEC:CMS will set the GP keys back to the default values as set in ROOT, ENC, MAC and DEK. Contact Versasec for details on what cards, GP and applets that can be managed in this way.