Alauda P38 is a mobile PKI applet for SIM/USIM cards. The applet works together with the Kiuru MSSP platform to deliver a local signing solution with highly assured control of PKI keys. User’s private keys are always kept on the SIM card which assures user sole control of the key.
Key Features
- Onboard key generation of RSA and ECC Keys with NIST-P curves
- Up to 8 PKI keys and PINs per user
- Two-factor authentication (2FA) with out of band transaction approval
- End-to-end message security
- Compatible with eSIM
- Supports up to 4 languages by default with additional preloaded texts up to 7 languages
- Support for 3DES-3, AES symmetric key algorithms and SHA2-Family of digest algorithms.
- 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+
- SIM menu for changing Applet settings including PIN change and PUK generation
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).
Certificate Registration
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
Licensing
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 P38 implementation is copyrighted by Methics.