Alauda WPKI Client Specification

Alauda WPKI Client [Alauda] has been designed based on current best practices and long experience in implementing various WPKI clients. The key features of Alauda are the following:

  • Consistent user experience
  • On-board key-generation
  • Key management with multiple key groups and keys
  • Certificate registration
  • Generation of digital signatures
  • Secure message transport over the air
  • User language management
  • Signing key PIN management
  • Mobile terminated secure messages
  • Display text content
  • Presentation Signature “WYSIWYS”
  • Request for user input
  • Error and cancel processing
  • Testing and monitoring
  • Card platform portability
  • Applet life-cycle management

Alauda WPKI Client specification is a communication and interaction specification for a digital signing (PKI) Card Applet (Alauda Applet) stored on the SIM card. Together with user generated private asymmetric keys, a client based on the specification enables a mobile phone subscriber to receive and sign digital signing requests.

Consistent User Experience

Consistent user experience is the key requirement when a mobile user is using various identity services and when a third party is auditing MSSP system security. A security auditor must be able to verify precisely what has been show to the mobile user and what has been the mobile user’s response.
Alauda Applet display elements are explicitly controlled by Alauda Protocol without any other dialogue flow control (like WML). Alauda Protocol does not contain invisible elements which could be used to forge user dialogues. Alauda protocol also uses explicit character encodings, and this is how signed content can always be verified with the original request.

Alauda binds PIN entry dialogues with key groups. This feature makes PIN dialogue usage consistent for the mobile user and makes it easy to prepare dialogues that are in line with a Certification Practice Statement [CPS]. An Application Provider cannot affect the most critical user displays. XML based Alauda message representation at the server side illustrates the user experience.

On Board Key Generation

Alauda Applet sample implementation utilizes the standard Java Card platform interface that is able to generate the public/private key pair on a SIM card. Alauda delivers the generated key-pair’s public key value out from the SIM to the system who requested for the key generation. Additionally, the public key can be requested from the Alauda Applet afterwards. This feature allows disaster recovery and migration functionality if user certificates must be renewed. Alauda v1 Specification describes support for 512 to 4096 bit RSA keys. The requested key length is defined in a key generation request.

Key Management with Multiple Key Groups and Keys

Alauda Applet can serve multiple mobile user identities and separate identity management systems at the same time. In this way the mobile user can have multiple identities and keys for e.g. banking usage issued by a bank (such as authentication and signing identities), and separate identities for citizen and employee identities issued by other identity issuers (CAs). This is done by using an Alauda Key Group and reserving specific key identifiers for each Identity Issuer.

The Figure 1 depicts how Alauda Key Group is constructed. The Alauda key identifier is an 8-bit integer which identifies a key group and a key in the group.

Signing Key PIN Management

A PIN length can be from 4 to 12 numbers and it is defined in the key generation request. When the RA requests to generate a new key, Alauda Applet asks the user to enter a PIN twice. If the PIN numbers are equal, Alauda Applet creates a new key.

Signing Key and PIN Life Cycle

  1. A key pair is born during the generation inside the Applet. The PIN that controls access to the key pair is created during the generation by asking it from the user, and storing it inside the Applet.
  2. All accesses to the key pair require the correct entry of that PIN.
  3. Too many successive failures on PIN entry (usually defined as 3) cause the PIN and all keys under its control to be irrevocably destroyed.

To help a blocked PIN user to return to the WPKI service, a blocked PIN can always be unblocked by:

  1. Recycling all key pair storages under the control of the PIN being recycled (destroying the former key material)
  2. Recycling the blocked PIN storage
  3. Running the key pair and PIN initialization as described above

There is no PUK to unblock a PIN.

Certificate Registration

The Alauda Applet supports the producing of PKCS#10 CSR and CMP/CRMF signatures. Alauda Applet wraps the certificate request in a cryptographic envelope that is valid data for a CA without any byte transformations.

Generation of Digital Signatures

The Alauda Applet can produce various kinds of CMS/PKCS#7 signatures as per [CEN1] [CEN2]. The Alauda Applet uses the standard PKCS#1v1.5 signature primitive and envelope in digital signature production. Supported signature formats in Alauda version 1 are

• CSM signature, CMS countersignature
• PKCS#1, PKCS#7 and PKCS#10

Secure Message Transport over the Air

The communication from the server to the Alauda Applet and back uses Alauda Encryption. Alauda Encryption uses a dedicated 3DES (or AES) symmetric key pair for message encryption. These keys are similar to OTA keys, and they are installed at the SIM factory during the card personalization phase.

Presentation Signature – WYSIWYS

In Alauda Version 2 the Presentation Signature follows the CMS signature creation procedure. It works as follows:

The Data To Be Signed (DTBS) is always explicit UTF-8 text (i.e. always in the format the AP requests, and no implicit text presentation is supported). Together with DTBS, an MSSP may provide Additional Signed Attribute parameters as CMS formatted attributes, like CAdES data element digest of the user certificate.
Alauda WPKI Client processes:

  1. Calculate digest over the original DBTS data (Hash1)
  2. Convert DTBS to SAT display format (DTBSF does UCS-2 conversion and adds paging support if necessary)
  3. Display DTBS, ask for OK
  4. Optionally display Signed Attributes, ask for OK
  5. Add Signature Object supplied Additional Signed Attributes and the Hash1 as per CMS
  6. Calculate digest over the produced Signature Object as per CMS (Hash2)
  7. Request for a signing PIN
  8. Do the sign operation over the Hash2 as per CMS
  9. Return the Signature Object, and plain Signed Attribute values


The Alauda WPKI Client consists of an Alauda WPKI Client Specification and a corresponding Alauda Implementation. The specification completely defines the Alauda Client interface and the Alauda Protocol byte encoding.

Alauda M2 and P38 are copyrighted by Methics.

An Alauda implementation is owned by its implementer. Licensing terms of an implementation are up to the implementer.