Managing Mobile App Certificates

Important:
In previous versions of CMS, mobile app certificates were derived credentials that were only available for users that already had an initial device issued to them (for example, a smart card or a smart USB key). Starting in CMS 6.5, this is no longer applicable and users can issue mobile devices with credentials that are not derived from another device (using the Self-Service Portal). Nevertheless, it is still possible to issue derived credentials as in previous versions of CMS.
Note:
Current limitations:

  • It is only possible to issue a mobile device using a Microsoft or Entrust CA.

  • On a mobile device, it is not possible to create an encryption certificate. It is only possible to recover an encryption certificate from another device.

  • For a mobile-only deployment, it is only possible to issue authentication certificates.

Mobile app certificates are managed similarly to smart cards, in that:

  • They can be enrolled in the User Portal or the HID CMS Self-Service Portal. (This setting must be enabled; for details, see Setting Parameters for Devices.)

  • They can be managed in the Help Desk.

However, they differ with respect to smart cards in that:

  • Only basic Help Desk operations (Hold/Resume/Applications Update/Terminate) are available.

  • Only basic operations are available in the User Portal or HID CMS Self-Service Portal (for example, device update, but no reporting of a lost device).

  • There is no PIN application.

  • Enrollment of mobile app certificates is not available in the Operator Portal.

In previous versions of CMS, mobile devices containing mobile app certificates were considered “secondary” devices, as opposed to smart cards or smart USB keys being “primary” devices. This meant that mobile app certificates could only be issued for users that already had a primary device. In a FIPS 201 Federal Information Processing Standard 201 (NIST standard for HSPD-12/PIV).-compliant environment, these mobile app certificates are considered “derived PIV credentials.” For more information, refer to About Derived Credentials.

However, starting with CMS 6.5, you can issue mobile devices with mobile app certificates that are primary devices, without using a credential shared with another "primary" (initial) device.

Note: It is still possible to issue mobile devices using derived credentials as in previous versions of ActivID CMS.
Note:

  • For mobile app certificates, this version of ActivID CMS supports Apple devices (phones, tablets) running iOS 18 or higher.

  • For the issuance of mobile app certificates, this version of ActivID CMS supports both the Microsoft and Entrust Certificate Authorities. You should contact your HID Global reseller for information about extended environment support.

Prerequisites for Using Mobile App Certificates

For details about issuing credentials (mobile app certificates) for mobile devices on the User Portal or the HID CMS Self-Service Portal, refer to the ActivID CMS User online documentation or the HID CMS Self-Service online documentation, respectively.

Mobile Device Profile (for Mobile App Certificates)

ActivID CMS provides a dedicated profile for mobile app certificates used on mobile devices.

ActivID CMS Mobile Device Profile

Item

Description

Profile name

PIV 1024-2048 Profile for Mobile Devices

Profile description

Profile with PIV AUTH, PIV DIGSIG, PIV ENC keys for Mobile Devices

Supported feature(s)

  • One PKI application named PIV_AUTHENTICATION (mandatory)

  • One PKI application named PIV_DIGITAL_SIGNATURE (optional)

  • One PKI application named PIV_ENCRYPTION (optional)

PIN Policy

  • No PIN application
Note:

  • To support the issuance of mobile app certificates for mobile devices, a CA of the “Microsoft Certificate Authority” or “Entrust Certificate Authority” type is required.

  • When configuring the applications of the mobile device profile, only the certificate templates that do not archive the subject's encryption private key are available for selection.

For more details about this device profile, refer to Mobile Device Profiles (for Mobile App Certificates).

About Derived Credentials

In previous versions of ActivID CMS, the ability to issue credentials (mobile app certificates) on a mobile device depended on the existence of another credential managed by ActivID CMS, considered a “primary” credential: a smart card or a security key. The enrollment process required for the issuance of the primary credential, such as capturing user data (name, email address, phone number, picture, fingerprint, ID or passport documents, etc.) and the following vetting system (background check, identity proofing), did not need to be repeated when issuing new credentials to the same user. Instead, ActivID CMS would issue a new credential (“derived credential”) to the same user based on the validity of the earlier credential (“primary credential”). This type of enrollment is still possible in the current version of CMS, but it is no longer mandatory and mobile devices can be issued with their own credentials that are not shared with any other device.

ActivID CMS will maintain a link between the primary and derived credentials – but each credential will contain separate certificates and have their own lifecycle. For example, a user may get a replacement device and keep the same mobile app certificates unchanged; or vice versa, a user may get a new phone, without impacting his/her smart card.

In the case of encryption certificates, ActivID CMS will issue the same encryption certificate on all devices assigned to a given user, to enable viewing encrypted emails whatever system is used to access them (for example, a Windows PC or a mobile phone).

ActivID CMS is designed for compliance with “Derived PIV Credentials,” as defined in NIST National Institute of Standards and TechnologyFIPS Federal Information Processing Standard 201-2 and NIST SP 800-157. In this model, the “primary credential” is a PIV, PIV-I or CIV card, containing Authentication, Signature and Encryption certificates, and the associated mobile device (phone or tablet) is a “derived PIV credential” also containing Authentication, Signature and Encryption certificates.

For each user, the primary device (PIV, PIV-I or CIV card) must be issued first. New authentication, signature and encryption certificates are present on each card; the encryption certificate is escrowed on the CA by ActivID CMS and now considered a “shared encryption credential.” In this case, when the mobile app certificates are issued, new signature and authentication certificates are created for the mobile device; the CA-managed certificate is recovered on the mobile device.

For added security, the system can check the validity of the primary device (PIV device) again 7 days after the issuance of a PIV derived credential. If the PIV device had been reported as stolen during that period, the mobile device is then terminated.

Important:
Starting in CMS 6.5, the automatic process named “PIV Check 7 days” (used for derived credentials) has been deactivated by default.
If you are using derived credentials to issue mobile devices and want to enforce this PIV directive, the following procedure enables the re-activation of the automatic "PIV Check 7 Days" process:

  • In the AP_MANAGERS table of AIMSEE database, update the row with the chk7daysMgr key by setting ACTIVE to 1 as shown below:

    Copy
    UPDATE AP_MANAGERS SET ACTIVE = 1 WHERE MGRKEY = 'chk7daysMgr';

  • Restart the CMS service.

The link between a primary device and its derived device(s) is managed automatically by ActivID CMS: no additional operation is required from a Help Desk operator.

More specifically, this means:

  • Any revocation action performed on a shared encryption certificate automatically revokes the encryption certificates on all devices where it is present (card or mobile device).

  • When a user name changes, requiring a PIV device update, an operator can also request similar updates for any derived credentials.

  • Terminating a primary device (with no replacement issued) also terminates all its derived devices automatically.

Important:
To avoid inadvertent termination of derived credentials, it is not recommended to issue a derived credential from a temporary card or, in a FIPS 201-compliant environment, when the primary PIV credential is going to expire in less than 7 days.

Examples of Typical Use Cases for Derived Mobile App Certificates

Important:
The information provided in this section only applies to derived mobile app certificates using the enrollment procedure required in previous versions of CMS.

In all the following cases, both the primary PIV device and the derived mobile device are intended to each have 3 certificates:

  • 1 authentication (AUTH) certificate

  • 1 signature (SIGN) certificate

  • 1 encryption (ENC) certificate.

The encryption certificate is shared between the PIV device and the mobile device.

The PIV device initially contains 3 credentials:

  • AUTH_1: authentication certificate

  • SIGN_1: signature certificate

  • ENC_1: encryption certificate

The PIV device also stores historical encryption certificates whereas the mobile device by default stores only the newest encryption certificate (index set to 1).

The certificate status is indicated by its color:

  • Active

  • On Hold

  • Revoked

The end user has a PIV device with 3 credentials (AUTH_1, SIGN_1, ENC_1) and a mobile device with only 1 authentication certificate (AUTH_2). The organization now wants to extend capabilities provided on the mobile device by adding 1 new signature certificate and 1 encryption certificate (shared with the PIV device).

Initial state:

  • The PIV device is active, as well as all its credentials.

  • The mobile device is active as well as its credential (1 authentication certificate).

Operations:

  1. Create an applications update request for the mobile app certificate (using the Help Desk). For details, see Requesting an Applications Update.

  2. Execute the applications update request on the mobile device (using the User Portal). For details, refer to the ActivID CMS User online documentation.

Result:

  • The mobile device now has 3 certificates: 1 new signature certificate (SIGN_2) and 1 recovered encryption certificate (ENC_1, from the shared encryption credential of the PIV device), in addition to the existing authentication certificate.

    Operation

    PIV Device

    Mobile Device

    1. Initial state

    AUTH_1

    SIGN_1

    ENC_1

    AUTH_2

    2. Create applications update request for mobile app certificates (Help Desk)

    AUTH_1

    SIGN_1

    ENC_1

    AUTH_2

    3. Execute update request on mobile device (User Portal)

    AUTH_1

    SIGN_1

    ENC_1

    AUTH_2

    SIGN_2

    ENC_1
    Important:
    Since only one mobile app certificates device policy can be defined at a given time, you will need to unassign the old policy for previously issued mobile app certificates in order to perform an update. Make sure that the Initial Issuance assignment is selected for the target device policy.

The PIV device was declared as lost or stolen and its credentials are suspended. The mobile device is unaffected, except for the shared encryption credential.

The replacement PIV device is issued and has a new encryption certificate so the mobile device needs to be updated in order to have the same shared encryption certificate.

Initial state:

  • An incident has been declared for the PIV device.

  • The derived mobile device is active but its encryption certificate is suspended.

Operations:

  1. Issue the replacement PIV device. For details, see Requesting a Replacement Device. (The initial PIV device is then terminated automatically).

  2. Create an applications update request for the mobile app certificates (using the Help Desk), in order to recover the new encryption certificate (manual operation). For details, see Requesting an Applications Update.

  3. Update the mobile device (on the User Portal). For details, refer to the ActivID CMS User online documentation.

Result:

  • The replacement PIV device is issued with 3 new credentials as well as the previous encryption certificate (recovered). This device becomes the current PIV device for the end user.

  • The initial PIV device is terminated and its credentials are revoked (since it was declared lost or stolen).

  • The mobile device is updated by adding the new encryption certificate shared with the replacement PIV device.

Operation

Initial PIV Device

Replacement PIV Device

Mobile Device

1. Initial state

AUTH_1

SIGN_1

ENC_1

N/A

AUTH_2

SIGN_2

ENC_1

2. Issue replacement PIV device

 AUTH_1

SIGN_1

ENC_1

AUTH_3

SIGN_3

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_1

3. Terminate initial PIV device

AUTH_1

SIGN_1

ENC_1

AUTH_3

SIGN_3

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_1

4. Create applications update request for mobile app certificates (Help Desk)

AUTH_1

SIGN_1

ENC_1

AUTH_3

SIGN_3

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_1

5. Update mobile device (User Portal)

AUTH_1

SIGN_1

ENC_1

AUTH_3

SIGN_3

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_2

ENC_1

Note: After a mobile device is updated with a new encryption certificate, the former certificate remains installed on the device unless it is manually removed; however, it is no longer displayed in the device profile on the Help Desk.

The mobile device containing mobile app certificates must be terminated (for example, declared lost or stolen) and new mobile app certificates need to be issued for the replacement device.

After the mobile device is terminated, its associated primary device (PIV device) needs to be updated in order to add a new encryption certificate. Then (and only then) the new mobile app certificates are issued, including the new encryption certificate that has been added to the PIV device.

Initial state:

  • The PIV device is active, as well as all its certificates.

  • The mobile device is active, as well as all its certificates, but needs to be terminated.

Operations:

  1. Terminate the initial mobile device (manual operation). For details, see Terminating a Device.

  2. Create an applications update request for the PIV device, in order to add a new encryption certificate (manual operation). For details, see Requesting an Applications Update.

  3. Update the PIV device. For details, see Updating Applications on Devices.

  4. Issue a new set of mobile app certificates for the new mobile device (on the User Portal or the HID CMS Self-Service Portal). For details, refer to the ActivID CMS User online documentation or the HID CMS Self-Service online documentation.

Result:

  • The PIV device has an additional (new) encryption certificate.

  • The initial mobile device is terminated. Its credentials (mobile app certificates) are revoked.

  • A new set of mobile app certificates are issued which contains the newest encryption certificate (shared with the PIV device).

Operation

PIV Device

Lost/Stolen Mobile Device

New Mobile Device

1. Initial state

AUTH_1

SIGN_1

ENC_1

AUTH_2

SIGN_2

ENC_1

N/A

2. Terminate the mobile device (mobile app certificates)

AUTH_1

SIGN_1

ENC_1

AUTH_2

SIGN_2

ENC_1

N/A

3. Create an applications update request for PIV device

AUTH_1

SIGN_1

ENC_1

AUTH_2

SIGN_2

ENC_1

N/A

4. Update PIV device

AUTH_1

SIGN_1

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_1

N/A

5. Issue a new set of mobile app certificates for new mobile device

AUTH_1

SIGN_1

ENC_2

ENC_1

AUTH_2

SIGN_2

ENC_1

AUTH_3

SIGN_3

ENC_2