Smart Card/Security Key Credential Issuance
This tutorial helps you to learn more about the available options in the Smart Card/Security Key Credential Issuance section while creating a workflow.
The Unifyia platform complies with the National Institute of Standards and Technology (NIST) and FIPS
201-3 standards for the Personal Identity Verification (PIV), Commercial Identity Verification (CIV), Derived PIV (DPIV), and Derived FIDO
(DFIDO) credential issuance on smart cards and security keys.
This section is the most critical and complex aspect of the workflow as it allows you to configure the
chip personalization and printing options for devices such as smart cards or security keys. All the options
selected in this section are executed during the chip personalization and printing steps during the
issuance of an identity device. The visibility of certain configurations is dependent on the identity
type and device profiles selected. Hence, ensure to first complete the general section configurations
before configuring the parameters in this section.
What can you configure in this section?
- Select applets (PIV, FIDO2) to load on the smart card/security key if the selected device
profile does not contain any applet.
- Configure personalization and printing options.
- If printing is to be done, then select visual designs based on the Identity type selected.
- If the smart card/security key contains both PIV and FIDO2 applets, select which application to
use to issue credentials.
- Configure the certificate types to be issued from the selected Certificate Authorities.
- Enable key escrow for the key management certificate.
- Configure if revocation of the key management certificate needs to be disabled.
- Define if signing the data being saved in the smart card/security keys containers is mandatory
using the content signing certificate.
- Set notifications for expiring certificates.
- If you are issuing a DPIV or DFIDO2 credential, configure if verification of the issuance status
of the primary credential is essential.
- Configure if activation is required.
- You can configure to issue certificates to selected device profiles. Depending on the device profile,
various issuance options are available. Select the option you would like to enable and specify the
group(s) that should be granted access to perform the particular action.
- You can configure loading the applets if the smart card selected does not have
PIV or FIDO2 applets which are required for personalization. For example, ZTPass on NXP P71D600 cards do
not contain any applet. So, if you wish to issue such cards, you can select the type of applet to be
loaded during the issuance process.
Applets
This section is visible only if you have selected the device profile as ZTPass on NXP P71D600. These devices
do not contain any applet. Hence, it is essential to load PIV or FIDO2 applets on the card before
personalization. If you have selected the JCOP4 and/or JCOP4.5 device profiles and checked the option
Smart Card/Security Key Credential Issuance, then you need to select at least one or both of the below
options based on your requirements:
- Enable PIV Applet Loading: Select this option to load the PIV applet on the
JCOP4 device before personalization.
- Enable FIDO2 Applet Loading: Select this option to load the FIDO2 applet on the
JCOP4 device before personalization. Enter the following details:
- Attestation Certificate: Provide the Attestation Certificate in
Hexadecimal Format. This certificate is authenticator specific or authenticator
model-specific attestation certificate issued by the manufacturer.
- Attestation Certificate Private Key: For the manufacturer-issued
attestation certificate, provide the attestation certificate private key in Hexadecimal
Format. This key will be used to validate the attestation.
- AAGUID: Enter an AAGUID for the selected product type. An AAGUID (Authenticator
Attestation Global Unique Identifier) is an identifier for FIDO2 security keys. The same
AAGUID is assigned to security keys whose product type and firmware are the same. For
AAGUIDs assigned to security keys, contact the manufacturing vendor. Some manufacturing
vendors release AAGUIDs on their websites.
Chip Personalization and Printing
This section allows you to configure the chip personalization and ID printing options. You must choose at
least one option to proceed.
- Enable Chip Personalization: Check this option if you only want to allow the
personalization of devices like smartcards or security keys. Select the group(s) that should be
granted access to perform chip personalization.
- Enable Chip Personalization + Visual ID Printing: Check this option if you
intend to allow personalization and printing cards. Select the group(s) that should be granted
access to perform this action.
- Enable Visual ID Printing: Check this option to enable the printing of visual
identities. Select the group(s) that should be granted access to print IDs.
Select Visual Designs
This section is enabled only if you have selected a printing option that has visual ID printing. The
groups that you have selected under the General section are auto-populated. Select a visual design for
each group from the listed options in the drop-down. Based on the identity type selected, the visual
designs are populated. For instance, if you've selected to issue a PIV ID, then the PIV ID visual design
will be presented in the drop-down list. You can include multiple designs for a single identity type and
proceed with issuance accordingly provided that you have already added the required visual designs.
Select Applications
The options within this section are exclusively enabled for identity devices equipped with both PIV and
FIDO2 applications. For instance, devices such as Yubikey 5 and IDEMIA PIV V8.2 support both
applications. Also, if you have loaded both the PIV and FIDO2 applets on the smart cards such as ZTPass on NXP P71D600, then there are two applications on the device. This section allows you to specify which application to personalize. Follow these steps to view and configure this option:
- Select the device profile as Yubikey 5, IDEMIA PIV V8.2, or ZTPass on NXP P71D600 cards, and select to load an applet (either PIV or FIDO2 or both).
- Select Smart Card/Security Key Credential Issuance.
- Select either Enable Chip Personalization or Enable Chip Personalization + Visual ID Printing.
- Based on your organization’s requirements, select PIV, FIDO2, or
both.
- This configuration is implemented during the identity issuance process, specifically during
personalization.
Certificates
Include this section in the workflow to configure the issuance of various certificates for smart cards
and security keys during personalization. These certificates serve purposes such as certificate-based
authentication, digital signatures, and more. Within this section, you can specify settings to receive
notifications for expiring certificates. Additionally, you have the flexibility to configure the
issuance of different types of certificates: either from a single certificate authority or from
different certificate authorities for each certificate.
Certificate Types
The following are the certificates that can be configured and used for various functions.
- Card Authentication - This certificate is used to identify the card. It is a
certificate and key pair that can be used to verify that the credential was issued by an
authorized entity, has not expired, and has not been revoked.
- PIV Authentication - This certificate is usually known as a user authentication
certificate as this identifies the user and is used in Windows login (smart card logon), Web
SSO, etc.
- Digital Signature - This is a digital signing certificate used for signing
emails and documents.
- Encryption - This is a key management certificate and is used to encrypt
sensitive data that is stored on the PIV card. It facilitates the secure storage of
cryptographic keys on the PIV card. For more information read about the Key
Management Certificate.
Follow the steps below to configure the certificates for the smart devices:
- Certificate Type: Select the type of the certificate to be issued. There are
four types of certificates that you can issue – Card Authentication, PIV Authentication,
Digital Signature, and Encryption.
- CA Server: Select the Certificate Authority from which the certificate needs to
be issued.
- Certificate Profile: Select the certificate profile created in the
Certification Authority.
- Escrow: Select this option if the encryption or the key management certificate
needs to be escrowed and moved to the retired containers. Enabling this option allows you to
support key and certificate recovery during future device issuances leveraging the same
workflow. Key Escrow for the Key Management certificate occurs at the certificate authority. Key
Escrow for the other 3 certificates is not available for security best practice. For more information read about the Key Management Certificate.
- Disable Revocation: Select this option if you want to disable the revocation of
key management certificates on the expiry of the identity device. For more information read about the Key Management Certificate.
- Algorithm: Select the algorithm type, e.g., ECDSA, RSA.
- Key Size: Select the key size based on the selected algorithm, e.g., 256, 2048, etc.
- Subject DN: Select the list icon under the Subject Distinguished Name (Subject
DN) column and define a format for the DN pattern for each certificate. Select the
Tick icon to save or the Cross icon to cancel it. Currently,
the application supports user.commoname, org.organizationUnit, and org.organization, e.g., cn,ou,o.
- SAN: Select the list icon under the Subject Alternative Name (SAN) and define the identifiers
that you require to be included in the X.509 certificate to identify the person the certificate
represents. You may select one or more Subject Alternative Name (SAN) entries. The following are
the supported SAN entries:
- Other Name: Refers to a flexible and extensible field that allows for
the inclusion of alternative identities not covered by standard SAN types.
- RFC822 Name: It is an email address.
- Uniform Resource Identifier (URI): It is a string that uniquely
identifies a particular resource. Can be a URL (Uniform Resource Locator) or URN
(Uniform Resource Name).
- Actions: Select the Plus icon to add a row to configure
another certificate type and set the values as explained above. You can add a maximum of four
certificate types. Select the Cross icon to delete a row.
The Unifyia platform uses a Certificate Authority (CA) to issue four types of
certificates – PIV Authentication, Card Authentication, Digital Signature, and the
Key Management Certificate. A Key Management Certificate is a digital certificate used
to manage and secure keys within a system. It is crucial for handling key-related
operations such as encryption, decryption, signing, and verifying digital signatures.
The private keys of the Key Management Certificate issued by a Certificate Authority are
stored on the Certificate Authority if escrowed. The Unifyia platform offers two
configuration options for the Key Management Certificate – Escrow and Disable
Revocation. Let’s explore these two options in detail:
Escrow
When you enable the Escrow option for the Key Management certificate in a workflow on the
Unifyia platform, the private keys for the certificates are stored on the CA server.
These keys are retrieved during the reissuance of an identity device if the original
device is lost, damaged, or stolen, or when issuing an additional device for the same
user. If the option is disabled, a new certificate is generated and installed for each
device issued.
Disable Revocation
When you enable the Disable Revocation option, the key management certificate remains
valid even if the identity device has expired. This helps the organizations to maintain
uninterrupted access to services relying on the Key Management certificate.
Organizations can avoid the need to frequently update and manage certificate statuses.
This simplifies certificate lifecycle management, especially in environments with many
devices and certificates.
Multiple Identity
Devices Issuance - Escrow and
Disable Revocation Use Cases
This section explains how the Key Management certificate is managed with the Escrow and
Disable Revocation options while issuing multiple identity devices.
- When a user is issued multiple devices, a single Key Management certificate is
issued by the CA and shared across all devices if the Key Escrow option is enabled
in a workflow. However, the other three certificates (Card Authentication, PIV
Authentication, and Digital Signature) are issued independently for each device and
cannot be shared among the available devices.
- If the Card Authentication, PIV Authentication, or Digital Signature certificates
expire or are nearing expiration, you can renew the device. This will regenerate and
load the new Card Authentication, PIV Authentication, and Digital Signature
certificates into the device. If the Key Management certificate expires, all
certificates, including the Key Management Certificate, will be regenerated and
loaded into the device.
- An expired or revoked Key Management certificate is moved to the retired container
of the device if the Escrow option is enabled.
- If the Disable Revocation option is enabled for the Key Management Certificate,
actions like Revoke, and Reactivate do not affect the Key Management Certificate.
When renewing any expired certificates, the three certificates are regenerated and
loaded into the device, but the existing active Key Management Certificate is
retrieved from the CA and placed in the device.
Additional Configurations
You have options to writeback to multiple directories. For example, you have set the first user
attribute mapper (e.g., hspd12issuancestatus) and certificate attribute as
X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER} with the directory
LDAPAD1. Select the + icon to add another row and select the second directory, for
instance, LDAPAD2, then select the second user attribute mapper (e.g., lastname) and
the corresponding certificate attribute for it as
X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER}. Based on the above
configuration, the issuance status of the derived credential is updated in both the selected
directories.
- Directory: Select the name of the directory configured for the organization
from where the user data is mapped.
- User attribute mapper: You can manually map the issued certificates to a user
in the directory using the altSecurityIdentitiesor hspdissuancestatus
attribute of the user's Object. Select the LDAP attribute mapper labeled as
altSecurityIdentities. The chosen certificate attribute value in the
selected format will be written back to the altSecurityIdentities LDAP
attribute. This enables to update the directory with the newly issued certificate. While
authenticating a user using a derived credential, the system cross-checks with this value and
trusts the certificate to allow access.
- Certificate Attribute: Select the format in which the issued certificate value
must be prepared and subsequently written back to the directory. The below format is recommended
as this is considered one of the strong mapping types recommended by Microsoft.
Format: X09:<I>{ISSUER_DN}<SR>{SUBJECT_SERIAL_NUMBER}
- Reverse certificate mapping as recommended by Microsoft for altSecurityIdentities:
This option allows you to mandate the reverse certificate mapping method to build the
value for the Certificate attribute. Microsoft recommends this as a best practice.
- Sign data written to card/token containers with issuer signing certificate:
Select this option to sign the data written to the smart card/security key containers with
issuer signing certificate for additional security. For this to be executed, ensure to upload
the Content Signing Certificate.
- Notify users of any certificates expiring in: Select a value to indicate when
to start sending the notification to the users informing them about the expiring certificates.
For example, if the value is set to 5, then 5 days before the expiration of the certificates,
the user is warned about the expiring certificates.
- Email Notification Frequency: Select a value to set the frequency of sending
notifications to the user about the expiring certificates.
Primary Credential Verification Configuration
This section is visible only if you have selected the identity type as Derived Credential (DPIV). This
section allows you to configure the parameters to verify the status of the primary credential before
issuing the derived credential which could be a Derived PIV or a Derived FIDO.
If you have chosen the Identity Type as Derived PIV, selected a device profile(s) for issuance of DPIV,
and checked the option for Smart Card/Security Key Credential Issuance, you need to configure the
following parameters to enable the issuance of a Derived credential using the existing PIV ID:
- Verify the issuance status of the primary credential prior to issuing the derived
credential: Check this option to mandate the verification of the issuance status of
the primary credential i.e. the PIV ID before the issuance of the derived credential. You must
specify the directory, user attribute mapper, and user attribute values that will be used to
confirm the issuance status.
- Directory: Select the name of the directory configured for the
organization from where user data is mapped.
- User attribute mapper: Select the LDAP attribute mapper
hspd12issuancestatus. This attribute will be cross-checked against the
specified attribute value thus enabling the verification of the primary credential's
issuance status.
- User attribute Value: Enter the value as ACT. This
prompts the server to verify if the selected user attribute mapper (hspd12issancestatus)
contains the value ACT. If it does, the primary credential is
considered successfully verified.
- Apply the policy exclusively to users and if required, grant operators the ability to
override it: Select this option if you want to enforce the verification of the
primary credential solely for the user and grant operators the authority to override the
verification if required.
- Read and Authenticate the Primary Credential: This option is automatically
enabled to facilitate the reading and authentication of the Primary Credential before the
issuance of the derived credential.
Derived Credential Lifecycle Configurations
As the derived credential is derived from an active primary credential, it's essential to maintain
synchronization with the primary credential's status. Thus, it's imperative to regularly monitor the
LDAP database for updates and promptly update the Unifyia platform accordingly. The lifecycle actions
for the derived credential include suspending, renewing certificates, and revoking them based on the
status of the primary credential. This section facilitates the configuration of status check parameters
to perform Renew and Update (Suspend, Revoke) actions on the derived credential based on the status of
the primary credential to update the platform accordingly.
Renew/Update
- Check the issuance status of the primary credential before proceeding
with the renewal of the derived credential: Enable this option to validate the
issuance status of the primary credential before proceeding with the renewal of the derived
credential. You must select the directory, the User LDAP Attribute, and the User Attribute value
LDAP that will be used to confirm the issuance status.
- Directory: Select the name of the directory configured for the
organization from where user data is mapped.
- User attribute mapper: Select the LDAP attribute mapper
hspd12issuancestatus. This attribute will be cross-checked against the
specified attribute value thus enabling the verification of the primary credential's
issuance status.
- User attribute Value: Enter the value as ACT. This
prompts the server to verify if the selected user attribute mapper (hspd12issancestatus)
contains the value ACT. If it does, the primary credential is
considered successfully verified.
- Verify the Certificate Revocation List (CRL) to confirm the issuance status of the
primary credential and suspend/revoke based on the status of the primary credential.
- Place credential on suspension status in response to a status change in the source
directory: Choose this option to align the status of the primary credential by
leveraging LDAP user attributes. Employ User Attribute Mappers to monitor the directory for any
changes and suspend the derived credential accordingly, mirroring the suspension status of the
primary credential. Specify the directory, user attribute mapper, and user attribute value
within LDAP to validate the issuance status. If the primary credential is suspended, ensure the
derived credential status is updated accordingly to reflect the suspension in the Unifyia
platform.
- Directory: Select the name of the directory configured for the
organization from where user data is mapped.
- User attribute mapper: Select the LDAP attribute mapper
hspd12issuancestatus. This attribute will be cross-checked against the
specified attribute value thus enabling the verification of the primary credential's
issuance status.
- User attribute Valsue: Enter the value as TRM. This
instructs the server to validate whether the selected user attribute mapper
(hspd12issancestatus) includes the value TRM. If the validation returns true, then the
status of the primary credential should be updated to suspended.
- Verify Status Every: Specify the frequency for performing the status
check by selecting a value from the drop-down.
- Place credentials on suspension status in response to the primary credential
certificates being suspended or revoked: Select this option to synchronize the
status of the primary credential by checking the certificate revocation list published by the
certificate authority at regular intervals. Provide the CRL URL to connect and check the status
of the primary credential. If the primary credential is suspended/revoked, then update the
status of the derived credential accordingly in the Unifyia platform.
- Certificate Revocation List URL: Provide the Certificate Revocation
List URL.
- Verify Status Every: Specify the frequency for performing the status
check by selecting a value from the drop-down.
Activation
Include this option in the workflow if verification is necessary before activating the device,
particularly when the issuance is conducted by an operator without the user being present. As a security
measure, devices are locked before being sent to the customer, and users are required to activate the
device upon receipt. This section allows you to configure verification policy options for activation. If
you only check the Activation option without selecting any verification policy, the Verify
with PIN option will be chosen by default.
- Verify with PIN: Select this option to enable activation of the identity device by
entering the PIN provided to the ID holder.