UICC card, called more familiarly a SIM card, contains a set of applications. These applications are managed by a mobile network operator and are installed during card manufacturing.

The main benefits of UICC applets compared to phone apps are their security (phone apps and their data are easy to access and modify) and their independence of mobile device.

In MSS, a user makes signatures using their mobile device. For this, we have developed an applet to securely make the signatures on user’s UICC card.

The card communicates:

• With a user through her phone’s screen.
• With the user’s mobile network operator via SMS.

We work mostly in Java and therefore it is a blessing that the de facto technology for UICC cards is Java Card. Still, you can imagine that Java Card applet development radically differs from our typical field, which is server-side development.

Difficulty

Updating an applet for millions of devices using SMS is not a slice of cake, and sometimes not possible at all. A bug in the applet could make it unusable for all deployed cards, and in the worst case break the whole card.

To make development more difficult the security in MSS must be excellent, the card code must be optimal and complex user interactions are required. A simple mistake could wreck a mobile operator’s business.

Challenge accepted! Our answer is to create a better-than-brilliant test solution called Alauda Test Engine.

Test Engine

The test environment has the required parts of mobile network and UICC card. We have the parts broken down to separate simulated components. This way responsibilities are naturally organized and the structure is clear.

Test Engine contains the following simulators:

• SIM Card factory, sends initial factory requests to a card
• Short Message Service Centre (SMSC), sends SMS requests to a card
• Alauda Messaging Server (AMS), helps with sending Alauda requests
• Mobile Station (MS), user communication (phone screen)

In the above picture, the “Test” orchestrates a single test run. It plays multiple roles, doing everything from registration to testing:

• Application Provider (AP): Signature requests
• Registration Authority (RA): Registration requests
• Mobile Network Operator (MNO): Support requests
• SIM Card Factory: Initial provisioning
• User: User interaction with mobile device
• Test: Test program, e.g. assertions

Dialogs

A typical user dialog (user interaction with phone screen) test has the following parts:

In parts 2 and 4 the test populate MS with user dialog responses. After this, in parts 3 and 5, the test sends an Alauda request to the applet via SMS. MS provides a populated response when the applet requests for user input.

This is what happens in requests that require user dialogs (2-3 and 4-5):

• Test populates MS with dialog responses.
• SMSC sends an Alauda request via simulated SMS.
• Alauda sends a request to MS if it needs user input.
• MS responds with the given dialog responses.
• Alauda sends a response to the SMS.
• Test checks that Alauda sent the expected dialogs and response.

Multiple purposes

The environment was built for use in later demo purposes later. The AP messages could come from a demo MSS service, instead of a pre-planned test.

MS could do much more than a simply transferring messages. It could host a web interface where a user can have simulated interactions with the applet. In this case the dialog requests would be displayed in the web interface and the responses would come from the web interface. This would result in very accurate demos.

The fact that the test environment can be taken out of context and used like this proves that the simulated components naturally present a real environment.