Creating a Device Policy

Prerequisites: Before you can create a device policy, you must have installed the appropriate certificate authorities and ActivID Authentication Servers (applicable if you want to personalize an SKI Symmetric Key Infrastructure application).

You can create a new device policy or duplicate an existing device policy. If you create a new device policy based on an existing one, then some of the fields are pre-populated with the information for that policy. You can change this information.

  1. Select the Configuration tab.

  2. Click Policies. The Policies page appears:

  3. Click Add Device Policy to create a new device policy.

    Alternatively, under Device Policies, locate an existing policy that you want to use as a template and then, in the Action column, click Duplicate. The Device Policy - Creation page appears:

  4. Important: There should only be one device policy for mobile app certificates assigned to a given user group. The same is true for virtual smart cards and YubiKeys (only one device policy for each per user group). If you want to change the Device Policy for any of these devices, you first need to unassign the original policy for Initial Issuance.
  5. In the Device Policy Name field, enter a name for the device policy.

    The device policy name:

    • Must be unique within ActivID CMS.

    • Must describe the device policy so that when you see the name in a list, you can easily recognize the device policy settings.
  6. In the Device Policy Description field, enter a more detailed description of the device policy.

  7. From the Device Type drop-down list, select OP_2.0 Smart Cards, PKCS#11 Devices, Mobile App Certificates, Mobile Smart Cards, Virtual Smart Cards, or YubiKeys.

    Note:
    • OP_2.0 Smart Cards correspond to Open Platform / Global Platform Java Cards with ActivID Applets or with standard PIV Personal Identity Verification (technical standard of "HSPD-12") Applets. In this mode, ActivID CMS manages cards securely using GlobalPlatform secure channel protocol. Cards with ActivID Applets, or with standard PIV applets, are managed in this mode.

    • PKCS#11 Devices correspond to cards that have a PKCS Public-Key Cryptography Standards #11 module. In this mode, ActivID CMS manages cards using the PKCS#11 protocol.

    • Note: ActivID CMS supports cards with a PKCS 11 module. Only one device profile is available for this device type, with 16 PKI PKI describes the laws, policies, standards, and software that regulate or manipulate certificates and public and private keys. slots available. Most device policies configured with PKCS 11 cards work the same way as they do with Java cards. However, there are a few limitations for PKCS 11 cards:
      • SKI is NOT supported.

      • Offline PIN unlock support depends on the PKCS#11 middleware.

      • Key escrow/recovery does not rely on GlobalPlatform secure channel.

    • Mobile App Certificates correspond to derived credentials issued to mobile phones, tablets, etc.

      Note: Only one device profile (PIV 1024-2048 Profile for Mobile Devices) is available for this device type. This profile has the following characteristics:
      • Description: Profile with PIV AUTH, PIV DIGSIG, PIV ENC keys for Mobile Devices.

      • Supports up to three PKI applications:

        • PIV_AUTHENTICATION (mandatory)

        • PIV_DIGITAL_SIGNATURE (optional)

        • PIV_ENCRYPTION (optional)

      • No PIN application. Access to a mobile device is typically protected by a PIN or other authenticator; this authenticator is not managed by ActivID CMS but may be managed by your Mobile Device Management system.

        For details, see Mobile Device Profile (for Mobile App Certificates).

    • Mobile Smart Cards correspond to virtual smart cards that are hosted on end-user mobile devices (phones, tablets).

      Important: Support for mobile smart cards has been deprecated starting with ActivID CMS 5.4.
      Note: Only one device profile (CIV - AI 2048 Crescendo Mobile Profile) is available for this device type. This profile has the following characteristics:

      For details, see Mobile Smart Card Profile

    • Virtual Smart Cards correspond to virtual smart cards that are hosted on end-user computers.

      Note: Only one device profile (Generic 1024-2048 PKI-Only Profile for VSC Devices) is available for this device type. This profile has the following characteristics:
      • Description: Profile with 16 1024-2048-bit PKIs for Virtual Smart Cards.

      • Personalization of up to 16 1024/2048-bit PKI keys and certificates.

      • Online unlock using User Portal (when enrollment on User Portal is enabled; see Setting Parameters for Devices.)

      • Offline unlock.

      • PIN Policy: Min length - 8 characters, Max length - 25 characters, Max number of tries – 5.

      For details, see Virtual Smart Card Profile

    • YubiKeys correspond to multi-protocol hardware authentication devices.

      Note: Only one device profile (YUBIKEY FIPS) is available for this device type. This profile has the following characteristics:
      • Description: Profile for YubiKey FIPS

      • Personalization of up to 24 2048-bit keys PIV PKI Objects (PIV Authentication, PIV Digital Signature, PIV Key Management Key, PIV Card Authentication, 20 Key Management Keys)

      • PIV EP Buffer Objects

      • 1 synchronous OATH Open Authentication_HOTP HMAC-based One-time Password Object loaded by ActivID CMS

      • PIN, PIV AUTHENTICATION, CHUID and Printed Information objects are mandatory. All other objects are optional.

      • In addition to the card pre-issuance keys, the following key must be present in the HSM for profile issuance.

      • YBTK_FINAL_ADMIN_KEY_9B_TRIPLE (24-bytes DES keys)

      For details, see YubiKey Profile.

  8. From the Device Profile drop-down list, select the profile to use when issuing devices with this device policy.

    A Device Profile specifies which and how many applications will be loaded on a device during the first phase of device issuance. The applications (such as PKI, SKI, or PIN applications) are personalized during the second phase of the device issuance (as are those populated with certificates, SKI credentials or other data). Some of the applications (also called slots) may stay empty during initial device issuance, and can be personalized during a device update at a later date.

    For details about the different device profiles available, refer to Device Profiles and Hardware Devices.

  9. Click Next. The Device Policy - Creation page appears:

    The example illustrates a policy using a CIV Crescendo C2300 FIPS device profile. The Device Policy - Creation page will be different when selecting other device profiles.

  10. In the Action column, select the task you want to apply to the corresponding application(s) in the Application Name column. See the following table for guidance.

    Device Policy Creation (Actions for PKI Applications and Other Applications)

    Action

    Operations Performed During Issuance

    Operations Performed During Applications Update

    PKI Application

    None/Remove

    PKI application is not selected.

    PKI application will not be personalized on the device.

    PKI application will be removed if it is in the initial device policy.

    Add

    PKI application will be personalized and added to the device.

    PKI application will be added if it is not in the initial device policy.

    Update/Add

    PKI application will be personalized and added to the device.

    PKI application will be added if it is not in the initial device policy.

    PKI application will be updated (removed and re-issued) if it is in the initial device policy.

    Other Applications

    None

    Application is not selected.

    Application will not be personalized on the device.

    Application will not be removed if it is already present on the initial device policy.

    Application will not be personalized if it is not present on the initial device policy.

    Add

    Application must be added.

    Application will be personalized and added to the device.

    Application will be personalized and added if it is not in the initial device policy.

    Application will not be updated if it is in the initial device policy.

    Important: When updating mobile app certificates, ActivID CMS adds certificates but does not remove any existing ones. As a result, the None/Remove action is not available when configuring an application for a mobile app certificates profile.

    The selected application names now appear in red (see the example of PIV_AUTHENTICATION in the following figure), which indicates that the application(s) have not been configured yet.

    This is an example showing how to configure a PIV_AUTHENTICATION application.

  11. In the Action column, next to PIV_AUTHENTICATION, select Add, and then click Configure.

    The Device Policy - Set Application Information page appears:

  12. Friendly Name—Enter a name that easily identifies the type of application you have selected for the device policy.

  13. Provisioning Method —Select Create Credential to create a new credential, or Recover Credential to use an existing credential, including a shared encryption credential.

  14. Note:
    • The Provisioning Method options are only available when one of the available CAs is configured to support credential recovery.

    • Selecting the Recover Credential option is the equivalent of setting the former Recover Application option (available in previous ActivID CMS versions) to Yes.

  15. Provider drop-down list—Select the type of Certificate Authority that will manage the certificates intended for the selected application.

  16. Certificate Authority drop-down list—Select the CA connected to ActivID CMS that issues the certificate for this application (for devices issued with this device policy).

  17. Template drop-down list—Select the template to use to issue the certificate. The template defines the usage of the certificate (for example, Windows login).

    Note: With the Microsoft CA, templates are filtered depending on their algorithm type and allowed key size to match with what is authorized for a given PKI application.
  18. User Name Prefix and User Name Suffix fields—Enter a prefix and suffix for the certificate (if applicable). These two fields are used to construct the certificate-friendly name for the certificate.

    Setting a certificate-friendly name enables you to identify easily the right certificate in your list of certificates.

    A certificate-friendly name is constructed as follows: <prefix><user_info><suffix>.

    The value <prefix> is a fixed string you specify in the User Name Prefix.

    ActivID CMS automatically retrieves the <user_info> and appends it to the prefix.

    By default, ActivID CMS takes the user common name. If a common name is not defined for the user, then the user identifier is used instead. The suffix is defined in the User Name Suffix.

    For example, assuming you are issuing a device to John Smith, set the following prefix and suffix:

    • Prefix: Authentication-

    • Suffix: -1

    The certificate-friendly name for the certificate becomes:

    Copy
    Authentication-John Smith-1

      You do not have to re-enter this information for each additional CA. After you have entered this for the first CA, these fields will appear pre-populated.

  19. Revocation Settings — By default, the credentials are revoked for all the listed states of the device (terminated, damaged, expired, updated, re-issued). You can clear the check box(es) to indicate any state(s) for which you do not want to revoke the credentials. For example, if you clear the Damaged check box, the credentials in a device in the Damaged state will not be revoked.

    Important: When defining a PKI application for a mobile app certificate device policy that recovers a shared encryption credential, all the Revocation Settings options are unchecked by default. The goal is to avoid revoking shared encryption credentials present on a mobile device when that device is terminated or updated in safe conditions, which would impact the same encryption credential present on another device, such as a primary smart card.
    Note: You can provide a revocation reason for each state of the device. For details, see Procedure 2: Updating a Connection to a CA
  20. Click Submit.

    The Configure PIV_AUTHENTICATION page appears:

  21. Apply any necessary changes for the PIV_AUTHENTICATION application.

    The default values come from the CA. Some of the fields are unconfigurable and unavailable. This depends on the interface that is configured between the ActivID CMS and each Credential Provider. For more information about Credential Providers, please contact HID Global Professional Services.

  22. Important: If you are using a Microsoft CA Credential Provider, then you can customize the Subject Alternative Name of the PKI application. For details, see Customizing the Subject Alternative Name for Microsoft PKI Applications
  23. Click Set.

    The Device Policy - Creation page reappears. The application name has changed from red to green to indicate that the application has been configured.

  24. When you have completed configuring the applications, click Save. A confirmation message appears.

  25. Click Done.

For detailed instructions on how to configure other application types, see the topics listed under Configuring Applications.