BlackBerry Certificates and Runtime

From idenprotect Knowledge Base
Jump to: navigation, search


When users get enrolled with the idenprotect Core Platform, there are a number of possible use cases. One of those use cases is to use the idenprotect mobile applications as an authentication delegate for BlackBerry Dynamics. If this is the use case you are planning to use, you will also need to ensure that you have configured one (or more) UEM servers.

This article discusses the generation of Key Pairs and how to allow BlackBerry Runtime access to that Key Pair. For other information about the UEM configuration, please see our UEM Guide

One of the advantages of using idenprotect as the Authentication Delegate on for Blackberry is that the idenprotect client can generate a key pair that is signed by the idenprotect Core Platform. This key pair is then made available to the Blackberry Runtime on the device so that it can be used to authenticate the user to services accessed via Blackberry Applications.

Please see UEM Certificates and CA for the required UEM configuration steps

Generation of Key Pairs

When the user authenticates to the idenprotect application they use either a biometric (Touch/ Face-ID) or device PIN. This unlocks the device's secure hardware and allows idenprotect to access its cryptographic capabilities.

Once the user has authenticated, the idenprotect client uses the unlocked secure hardware to create a key pair.

This key pair is known as an ephemeral key pair, because it is intended only to be valid for a very short period, eg 8 hours.

The mobile client creates a certificate signing request (CSR) for this key pair. It the digitally signs this CSR and submits it to the idenprotect Core Platform.

The idenprotect Core Platform validates the signature and signs the CSR, with using its own Internal CA or by forwarding the request to an external CA.

The validity period of the resultant certificate will be determined by the Certificate Template used to sign the certificate.

The signed certificate is then returned to the idenprotect Client. The idenprotect client combines the private key and public key into a P12 Key Store

Allowing Blackberry Runtime Access to Key Pair

There are two ways that the key pair created by the client can be made available to the Blackberry Runtime. The method used will depend on the level of support provided by the Blackberry SDKs for the versions of the Phone operating system and UEM server.

The two options are

  1. Injection Into the Blackberry Runtime
  2. PKI Connector

Injection into the Blackberry Runtime

In this use case, the idenprotect for Blackberry Client uses a Blackberry SDK API to inject the P12 into the Blackberry Runtime.


PKI Connector

An alternative, if the above method is not possible, is to use the idenprotect PKI Connector

A PKI Connector is a standard API that the UEM server can use to retrieve certificates for users from an external source. In this case, the external source is idenprotect Core Platform.

So the sequence is a little different. Once the P12 has been created by the client, the P12 is digitally signed by the client and uploaded to the idenprotect Core Platform.

The UEM server will then poll the idenprotect Core Platform, via the PKI Connector, to pull down the P12 for the user.

The P12 will then be injected into the Blackberry Runtime by the UEM server.


Using Certificates in Blackberry Runtime

Certificates/Keys that are injected into the Blackberry Runtime are available for any Blackberry Dynamics Application to use.

For example if a web-site or web-service has been configured for mutual TLS when Blackberry Access is used to access that site, it can use the key pair injected into the run time to establish the mutual TLS session.

In order to enable this the web-site or web-service should be configured to trust certificates issued by the idenprotect Core Platform.

idenprotect Authentication Portal


A specific example of a web service that can be configured to use Certificate-Based Authentication is the idenprotect Authentication Portal. This enables users to use the certificate in the Runtime to enjoy single-sign-on to services that are not set up for Certificate Based Authentication.

A typical use case is accessing Exchange On-Line via Blackberry Work.

With Exchange Online configured to work with ADFS and with ADFS configured to use idenprotect as a Trust Provider the resultant use case would be.

  1. User goes to access Blackberry Work
  2. User is asked to authenticate via idenprotect
  3. User authenticates to idenprotect and a signed ephemeral key pair is injected into the Blackberry Runtime
  4. Blackberry Work goes to Office 365 and is redirected to ADFS
  5. ADFS redirects to the idenprotect Authentication Portal with a SAML request.
  6. idenprotect Authentication Portal is configured for Mutual TLS and asks the Blackberry Work client if it has an appropriate certificate to authenticate the user
  7. The Blackberry Work provides the certificate that has been injected into the Runtime
  8. The mutual TLS handshake is completed using the private key from the key pair
  9. The user is now authenticated to the idenprotect Authentication Portal, and the Authentication Portal redirects the user back to the ADFS server with a SAML assertion
  10. The ADFS server validates the SAML assertion and redirects the user back to Office 365 with the required SAML assertion and WS-FED token to allow them access
  11. Users accesses their mailbox.

Note that ADFS is a requirement specifically for O365, for example of the user was accessing a service like Salesforce, ADFS would not be required in this flow


The ability to inject and use signed key pairs allows the user to enjoy single-sign-on to Certificate-Based Authentication enable web services and applications. Combining this with the idenprotect Authentication Portal, that can use Certificate-Based Authentication, means the user can also enjoy Single-Sign-On to SAML enabled web services

All this happens very quickly with little to no user input required.

If the user wants to access other SAML-enabled services in the same way, then they can do this again without any further need to authenticate.