Alauda WPKI Client is a wireless PKI (WPKI) client application for SIM/USIM cards. A WPKI client is needed for Mobile Operators to implement mobile subscriber’s WPKI service. WPKI service is a part of Mobile Signature Services [MSS] technology used Mobile ID and MobileConnect services.
- Onboard key generation of RSA and ECC Keys with NIST-P curves
- Support for 3DES-3, AES symmetric key algorithms and SHA2-Family of digest algorithms.
- Up to 5 PKI keys and PINs per user
- Two-factor authentication (2FA) with out of band transaction approval
- End-to-end message security
- Java Card 2.2.1, 2.2.2, 3.0.1, 3.0.4, 3.0.5, 3.1 with SAT/CAT Toolkit Release 5 and 6
- Supports up to 4 languages by default with additional preloaded texts up to 7 languages
- SIM menu for changing Applet settings including PIN change and PUK.
What is WPKI?
Wireless PKI (WPKI) is a concept of utilizing PKI on mobile devices. In a WPKI system, the mobile device has a secure element (e.g. SIM card) that holds the private key. The public key is is stored in a certificate during registration. The certificate is stored on the server side (e.g. MSSP).
In the Mobile ID service, the secure element contains a WPKI Client (Alauda P38) on a SIM card. A typical WPKI client implementation is a Java Card applet.
The certificate is stored on an MSSP (HomeMSSP) server. The user accesses an application which sends an authentication request to the MSSP (Acquiring Entity MSSP). The Acquiring Entity forwards the request to the HomeMSSP that belongs to the user’s operator.
The HomeMSSP sends the authentication request to the user’s mobile phone using the WPKI protocol.
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 up 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.
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
- 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.
- All accesses to the key pair require the correct entry of that PIN.
- 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:
- (Re)Running the key pair and PIN initialization as described above
- Using a PUK to unblock the PIN (Optional applet feature).
The Alauda Applet supports PKCS#10 CSR and CMP/CRMF type certificate requests. 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 are:
- CMS 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
Presentation Signature in Alauda 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:
- Calculate digest over the original DBTS data (Hash1)
- Convert DTBS to SAT display format (DTBSF does UCS-2 conversion and adds paging support if necessary)
- Display DTBS, ask for OK
- Optionally display Signed Attributes, ask for OK
- Add Signature Object supplied Additional Signed Attributes and the Hash1 as per CMS
- Calculate digest over the produced Signature Object as per CMS (Hash2)
- Request for a signing PIN
- Do the sign operation over the Hash2 as per CMS
- 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 implementations are copyrighted by Methics. An Alauda implementation is