Number of PKI Keys in Mobile ID Service

One of the main discussion topics in new Kiuru MSSP deployments has been the number of keys on the SIM card. Should there be a separate key for signing and authentication? How many PINs can the user actually remember? What kind of certificates is required?
The number of required keys is the theme question in all new Mobile ID deployments. The challenge is to define aspects, which affects or restrict the number of keys.
This article tries to elaborate the question and various options in real wireless PKI systems. We claim that no more than 5 keys are needed in a typical set-up. Lets define basic key terminology at first.

User Identity Binding

A user identity is defined in the certificate Subject and the certificate binds the Subject and the public key. PKI cryptography binds the public and private PKI keys. In the Mobile ID system, the PKI key pair is generated on the SIM card. The private key never leaves the SIM card and is protected by a PIN; multiple keys can be protected by a single PIN. The public key is sent to the MSSP and the MSSP takes care of the certificate. Figure 1 depicts these relations.

Public key and Subject binding.

The Kiuru MSSP system has two profiles which control key and identity bindings: Registration Profile and Certificate Profile. A user registration process cycle generates from one, up to five keys. For example, a registration process definition in the MSSP server’s registration adapter for 3 key registration consists of three Registration Profiles — one for authentication key (http://alauda.mobi/authn), one for document signing (http://alauda.mobi/nonRepudiation), and one for enterprise services (http://alauda.mobi/EnterpriseAuthn). Each one of these registration profiles generates a new key and requests a corresponding certificate from a CA.

This means that by default, the MSSP requests a certificate for all generated keys using the corresponding certificate profile. The certificate profile defines for example the certificate content and the CA for each certificate.

The Subject content consists of a set of attributes. Commonly, there are two kinds of Subjects aka Distinguished Names: pseudonym and real name certificates. Pseudonym certificate essentially defines only a unique subject without user’s real name attributes. Its the Relying Party’s responsibility to map the Subject to a real identity.

Real name certificates are an alternative approach. A real name certificate contains both user’s name (First name, Surname, Initials) and a unique serial number/identifier. In this case the Relying Party gets basic identity attributes and does not necessary need to verify user identity any further. Note that typically real names are not distinguished and in practice, the pseudonym and real name certificates should be handled equally.

As a conclusion we can say that the user may have as many identities as there are key pairs, the Subject does not restrict anyhow the number of keys.

Level of Assurance

Level of identity Assurance (LoA) depends on a trustworthiness of the registration process and the strength of the used cryptography technology. Kiuru MSSP Mobile ID solution supports three LoAs (LoA 2, 3 and 4). Different LoAs can be obtained easily by using different key lengths and registration processes.

Alauda applet’s LoA2 authentication is based on the same idea as the GSMA Mobile Connect LoA2 one-click-OK authentication. No PIN is asked and all user needs to do is press OK button. LoA3 and LoA4 user experience and technologies are the same and only the registration process assurance and the certificate content differs. LoA3 is used typically for enterprise applications and LoA4 for financial or national identity level applications.

Level of Assurance support requires multiple key support. Typically the LoA3 certificates are issued by user’s employer or bank and LoA4 certificate issuer is the government.

Key and PIN

When the key is generated, the user is asked at first to define a PIN and then enter the PIN again for confirmation. If two keys are generated, then user must enter a PIN altogether four times. This may be considered as a complicated user experience.
Alternatively, only authentication key is generated in the registration phase. In this way the user can generate the other keys afterwards by using the authentication key and a self-care portal. For example document signing keys can be generated only if user needs them. In this case we need to consider also user experience, when additional actions are needed from the user or how user can handle PINs.
Key and PIN binding is flexible and MNO may select various key grouping models. Number of PINs do not need to restrict number of keys anyhow.

Key Algorithms

Security of key algorithms are continuously under careful consideration. There are multiple parameters which needs to be considered when algorithm strength is defined. These are parameters like algorithm itself (RSA, ECC), key size (RSA: 1024-2048, ECC: 250-800) or used hash size (SHA-1 – SHA-256). Anyhow, the most important constraint shall be the resulting memory consumption on the UICC card.
Fortunately, Alauda applet key storage mechanisms and applet size are so small that memory consumption of the Alauda applet does not typically restrict number of keys.

User Experience

In most of cases we have been involved in, the user experience is a cultural question.

• How many PINs can the user remember?
• How many keys are needed initially?
• Is it ok to run registration process in multiple separate cycles or in a single cycle?
• How Helpdesk can advice users?
• Service pricing?
• Complexity vs security and competing technologies?

The most important decisions are made when these questions are answered. Success of the Mobile ID service depends on how the initial service model has been set-up to provide convenient and secure user experience, and these benefits must be higher than what competing technologies can provide.

Selecting Key Configuration

The Alauda P38 and Kiuru MSSP solution default configuration supports up to 5 different keys/key groups. The number of keys can be extended up to 16 keys per SIM card with configuration parameters. In practice, more than 5 keys is so rarely used that our conclusion has been that 5 keys match with the most of PKI systems and 5 keys are easier to manage.
We can organize keys for example as the following:

Written and Edited by: Jarmo Miettinen