WO2010023683A2

WO2010023683A2 - A method and system for client data security

Info

Publication number: WO2010023683A2
Application number: PCT/IN2009/000421
Authority: WO
Inventors: Shibu Gopalkrishnan; Suresh Anantpurkar; Dharavi Gade; John Kattakayam
Original assignee: MCHEK INDIA PAYMENT SYSTEMS PVT Ltd
Current assignee: MCHEK INDIA PAYMENT SYSTEMS PVT Ltd
Priority date: 2008-07-24
Filing date: 2009-07-23
Publication date: 2010-03-04
Anticipated expiration: 2011-01-24
Also published as: WO2010023683A3

Abstract

The invention relates a method of provisioning an application on to a mobile device comprising generating an encryption key based on a mobile device identifier to be used by the application to encrypt and decrypt persistently stored data; placing the encryption key in the application installation file and transmitting the installation file to the mobile device; storing the encryption key on the mobile device to be made available as a system property only to the application during its run time.

Description

The invention relates to client data security. In particular, the invention relates to client data security in mobile devices.

BACKGROUND

Mobile users with information computing appliances such as cellular phones or Personal Digital Assistants (PDA's) wirelessly communicate and interact with varied services and devices. The extensive use of mobile devices in the present day environment however raises the issue of safety in conducting financial transactions using such mobile devices. With the advancements in the field of mobile commerce and communication, secure authentication and secure transactions have emerged as the most important requirements for the M-commerce based environment.

Various applications are available for mobile devices for conducting transactions and in particular financial transactions. These applications are typically downloaded by the user on to the device and allow the user to conduct transactions after authentication is carried out using a password, personal identification number or a key. Some solutions have been proposed that address the security concerns in conducting transactions using mobile devices and in particular the storage of sensitive information on mobile devices. Such solutions include the use of encryption keys to encrypt sensitive data stored on the device. The sensitive information along with the encryption key is typically stored by the application in the persistent data storage of the device.

However, any data stored in the persistent data storage of an application, such as a J2me application, cannot be considered safe from hackers. In certain platforms such as Symbian the persistent data storage file may be transferred to a personal computing device using certain applications including FExplorer. The contents of the file transferred to a personal computing device, including sensitive information can be read.

Even if data stored in the persistent data storage is encrypted, it is still not safe as the key, process or sequence for encryption will be stored either in the code or in the persistent data storage, both of which are accessible. SUMMARY

The invention relates to a method of provisioning an application on to a mobile device comprising generating an encryption key based on a mobile device identifier to be used by the application to encrypt and decrypt persistently stored data; placing the encryption key in the application installation file and transmitting the installation file to the mobile device; storing the encryption key on the mobile device to be made available as a system property only to the application during its run time. The invention further provides for generating a key identifier for the encryption key, and placing the key identifier along with the encryption key in the installation file for transmission to the mobile device. In accordance with an aspect, the encryption key and/or the key identifier is placed in the configuration file of the application installation file.

The invention also provides for a method of encrypting or decrypting data on a mobile device comprising invoking an application capable of encrypting or decrypting data using an encryption key, the encryption key stored in a location other than the persistent data storage by the application management system of the mobile device and made available only to the application as a system property during application run time, and encrypting the unencrypted data stored on the data store of the application and storing the encrypted data on the data store of the application.

The invention further provides for the application including a key identifier linked to the encryption key and stored in the data store of the application; the method of encrypting or decrypting data on a mobile device comprising comparing the key identifier with a key identifier stored in the application configuration file; and using the encryption key to encrypt/decrypt data stored in the data store of the application if the key identifier stored in the application data store and the key identifier stored in the application configuration file match.

The invention also provides for a mobile device application capable of encrypting sensitive data comprising an encryption key to encrypt and decrypt persistently stored data, the encryption key stored in a location other than the persistent data storage by the application management system of the mobile device and made available only to the application as a system property during application run time. BRIEF DESCRIPTION OF DRAWINGS

The following is a brief description of the preferred embodiments with reference to the accompanying drawings. It is to be understood that the features illustrated in and described with reference to the drawings are not to be construed as limiting of the scope of the invention, hi the accompanying drawings:

Figure 1 illustrates a method of provisioning an application to a mobile user in accordance with an embodiment of the invention.

Figure 2 illustrates the method of encrypting/decrypting data on a mobile device in accordance with the teachings of the document.

Figure 3 illustrates a system to encrypt data stored on a mobile device in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof. Throughout the patent specification, a convention employed is that in the appended drawings, like numerals denote like components.

Many of the functional units described in this specification have been labelled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integration circuits or gate arrays, off-the-shelf semiconductors such as logic, chips, transistors, or the other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organised as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined together, comprise the module and achieve the started purpose for the module.

Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organised within any suitable type of data structure. The operational data maybe collected as a single data set, or may be distributed over different locations including over different member disks, and may exist, at least partially, merely as electronic signals on a system or network.

Reference throughout this specification to "one embodiment" "an embodiment" or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase "in one embodiment", "in an embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

In the context of this specification: a "JAVA platform" is a collection of related programs and libraries, which allow for developing and executing programs written in the JAVA programming language. a "MIDlet" is a JAVA application framework to be implemented on a JAVA enabled mobile device. The MIDlet may have the capabilities to show menus or web pages on the mobile device. MIDlet may be an interactive application which communicates with the mobile user. a "JAD file" is a JAVA Application Descriptor file. JAD file describes the MIDlet suite. The description may include configuration and profile details of the MIDlet suite. The JAD file may include location and size of a JAR file. a "JAR file" is JAVA archive file. JAR file is a bundle of many files into a single archive file. JAR file may contain one or more MIDlets described in the JAD file. a "Manifest" file is a file contained in the JAR file.

"Symmetric key encryption (3DES)" may be used for encrypting the data on the client or the user mobile device. Sensitive information stored in the user mobile device such as a personal identification number is stored as a hash value. The hash value of the personal identification number is encrypted with the key (3DES encryption) and this is stored in the client database or the persistent data storage. The personal identification number (PIN) acts as a gatekeeper to different functionalities within the MIDlet application. When a user enters a personal identification number (PIN) that needs to be validated, the stored encrypted value is decrypted using the key and verified. an "encryption Key" (Kl) may be a 16 byte value, which will be used as the key in the 3DES encryption / decryption of the data. a "key-version" or "key identifier" is a key identifier value that is linked to the encryption key Kl and also to the mobile number/device number - there by, uniquely identifying the user.

The invention provides for a method and system to encrypt data stored on a mobile device. The disclosure teaches using an encryption key to encrypt/ decrypt data that is persistently stored on the mobile device. The encryption key employed for encryption of data is not stored on the persistent data storage or the data store of the application. The encryption key is stored by the application management system of the device and provided to the application only as a system property during the application run time.

In accordance with an aspect, this disclosure teaches a method of provisioning an application on a mobile device. At the time of provisioning an application to the user mobile device, the application provisioning system generates an encryption key based on a mobile device identifier of the user. This encryption key is inserted in the installation file of the application and transmitted to the mobile device. The mobile device makes available these attributes to the application during its runtime. In accordance with an embodiment of provisioning an application on a mobile device, at the time of provisioning an application to the user mobile device, the application provisioning system generates an encryption key and a key identifier based on a mobile device identifier of the user. This encryption key and the key identifier are inserted in the installation file of the application and transmitted to the mobile device. The mobile makes available these attributes to the application during its run time. The key identifier is persistently stored in the persistent data storage or the application data store or the Record Management System (RMS) of the mobile device.

In accordance with an embodiment, the encryption key and/or the key identifier are stored in the application configuration file. The application management system extracts the attributes from the configuration file, including the encryption key and the key identifier and makes them available to the application during its runtime.

In accordance with an aspect the disclosure teaches of a mobile device application capable of encrypting sensitive data comprising an encryption key to encrypt and decrypt persistently stored data. The encryption key is stored in a location other than the persistent data storage by the application management system of the mobile device and made available only to the application as a system property during application run time.

The invention is further explained by way of example and illustration in a JAVA application to provide a fuller understanding and appreciation of the features of the invention. For the purposes of explanation, the example of a user wishing to download a Java application on to his or her device is described. The application is available with an application provisioning server. The user initiates the process by requesting a download of the application on the user mobile device.

Figure 1 illustrates a method of provisioning an application to a mobile user. The application may be provisioned to the mobile user in many ways including by way of a user interface on a web page or web link. In accordance with an embodiment, a mobile user sending a simple SMS to download an application is described here.

A mobile user may send an SMS message with a predefined keyword to the server indicating a desire to download an application. On receiving the SMS from the mobile user, the server examines the SMS and creates a session for the mobile user and generates a unique session ID for the mobile user. The server sends a dynamic WAP link with the unique session ID to the mobile user.

Once the user clicks the URL link, a response message is sent back to the server. The response message may include the details of the mobile device including the technical configurations details. On receiving the response message, the server decides whether a JAVA application descriptor (JAD) or Java Archive (JAR) which contains the Manifest file needs to be sent to the mobile user. The type of version of the application to be sent depends on the configuration of the user's mobile device. Most of the mobile devices are compatible with JAD files, but occasionally, for example, in some Motorola devices, a JAR file is sent by the server.

If JAD is the compatible file, the server creates an encryption key based on a random seed and a unique key identifier tied to this key. The encryption key and the key identifier are linked to the mobile device of the user. The server attaches the encryption key and the key-identifier into the JAD and sends it to the user. If the JAR is the compatible file, the server creates an encryption key and a unique key identifier and adds them to a manifest file present inside a JAR file. The server sends the JAR file to the mobile device of the user. The mobile device of the user installs the application on the mobile device. The application management system (AMS) of the mobile device extracts the encryption key from the JAD or the Manifest file and stores the same in a location other than the persistent data storage. Once the application is invoked, the application stores the key identifier in the persistent data storage. The encryption key is accessible only to the application during its run time as a system property.

Figure 2 illustrates the method of encrypting/decrypting data on a mobile device in accordance with the teachings of the document. Figure 2 also illustrates the steps involved during initial launch of the application and the method of updating keys. The validation or synchronisation may be done as background activity, not requiring user input or attention.

At step 100, on invoking the application provisioned in accordance with the teachings of this document, the application first checks if the key identifier is present in the persistent data storage or the local database, at step 102. When the application is invoked for the first time, the key identifier will not be present in the persistent data storage and the method moves to step 104 where the key identifier and the encryption key are queried as system properties and the key identifier is stored in the persistent data storage. Data, particularly sensitive data on the mobile phone is encrypted with the encryption key and stored in the persistent data storage, at step 106.

On subsequent invocations of the application, the key identifier will be present in the persistent data storage, and the method moves to step 108 where the application checks if the key identifier stored in the persistent data storage matches that stored in the configuration file used to install the application. If the key identifier stored in the persistent data storage matches that stored in the configuration file the application is successfully invoked, at step 110 and the encryption key is queried as system property and the data previously encrypted with the encryption key is decrypted and new data is encrypted, at step 112.

When an application is updated, a new encryption key and key identifier are generated and the old keys are archived at the server end. The updated client will have a new encryption key and a key identifier. After update when the application is invoked the key identifier stored the persistent data storage and the new key identifier will not match. Accordingly, the currently stored data encrypted with the earlier encryption key can no longer be used by the application until the data is migrated to the new encryption key. If the application has been updated or in the event of tampering with the key identifier, the key identifier stored in the persistent data storage will not match the key identifier provided in the updated configuration file, and the method moves to step 1 14. As the data in the database is encrypted using the earlier encryption key, the encryption key provided with the updated application will not be able to decrypt the data. Accordingly, the data stored in the database needs to be migrated to the new encryption key provided with the configuration file of the updated application. The method moves to step 116 where the key identifier stored in the persistent data storage and the key identifier available in the configuration file of the updated application are sent to the application provisioning server. The server checks if the key identifiers are valid for the user at step 118.

If the key identifier stored in the persistent data storage and the key identifier available in the configuration file of the updated application do not match, the method moves to step 120 where the user is informed that the application must be provisioned again so that the correct key identifier and encryption key are available on the device to decrypt the data.

If the key identifier stored in the persistent data storage and the key identifier available in the configuration file of the updated application match, the method moves to step 122, where the earlier encryption key that corresponds to the key identifier stored in the persistent data storage is encrypted using the new encryption key and sent to the client application. The application decrypts the message using the new key and obtains the old encryption key with which the data stored in the database is encrypted, at step 124. The application then uses the old encryption key to decrypt the data available in the database and re-encrypts the data using the new encryption key, at step 126. The application also replaces the key identifier in the persistent data storage with the new key identifier provided in the configuration file of the updated application, at step 128.

Figure 3 illustrates a system to encrypt sensitive data stored on a user's mobile device in accordance with an embodiment of the invention. Figure 3 includes a Mobile Device 200 and a Third-Party System or Application Provisioning Server 202. The Mobile Device 200 includes an Application Management System (AMS) 204 capable of communicating with the Third-Party System 202. The Application Management System 204 includes a User Interface 206, an Application Engine 208, an Application Handler 210 and a Record Management System (RMS) 212. A Third-Party System 202 includes a Mobile Interface 214, an Authentication Processor 216, and a Database 218. The Application Management System 204 present on the mobile device 200 may be directly connected to the Third-Party System 202 via the service provider.

The Application Management System 204 may be system software which may provide a runtime environment for JAVA application framework like a MIDlet built specifically for mobile devices 200. The Application Management System 204 may run on a JAVA platform like a J2ME platform. The Application Management System 204 manages the downloading of MIDlets and lifecycle of MIDlets.

The Application Management System 204 is provided with interfaces for the operating system of the mobile device 200. The Record Management System (RMS) 212 is a system for managing records. Record Management System (RMS) 212 provides a mechanism through which MIDlets can persistently store data and retrieve it later. MIDlets can only access the records created by them or by other MIDlets defined in the same package or suite. Once a MIDlet is removed from the mobile device, the associate records in the RMS 212 are also deleted automatically.

The Application Handler 210 may perform security related and data integrity related checks on the incoming messages. The Application Handler 210 may forward the verified message to the Application Engine 208.

The Application Engine 208 queries the key identifier as a System Property and stores it in the RMS 212. The Application Engine 208 is also responsible for validating the encryption keys sent by the Third-Party Server 202.

The Mobile Interface 214 may include a security protocol that performs security related and data integrity related checks on the incoming messages. The security protocol may be SSL (Secure Socket Layer), TLS (Transport Layer Security), PPP (Point-to-Point protocol) or any other protocol known in the art. The Mobile Interface 214 may connect a mobile device with an authentication server or a web server.

Authentication Processor 216 receives the message from the Mobile Interface 214. The Authentication Processor 216 creates a session which is linked to the user mobile device 200. The Authentication Processor 216 generates an encryption key and a key identifier to be sent to the mobile device 200. The Authentication Processor 216 attaches the encryption key and the key identifier to a JAD or Manifest file in JAR file to be sent to the mobile device 200.

By way of specific example, a method of provisioning a user mobile device with an application is described. For the purposes of explanation, the process describes an application for a J2me platform.

A user may access the user interface 206 on his mobile device 200 to send an SMS message with a predefined keyword to the Third-Party System 202 indicating a desire to download an application. The predefined keyword may comprise of a name of an application or software or a service. The keyword entered on the User Interface 206 by the user is passed onto the Application Engine 208. The Application Engine 208 communicates with the Application Handler 210 which receives the message and checks the data integrity of the message and forwards it to the Mobile Interface 214 of the Third- Party System 202. The Mobile Interface 214 assists the Third-Party System 202 to communicate with the mobile device 200. The Mobile Interface 214 may include a security protocol that performs security related and data integrity related checks on a message sent by the user. The Mobile Interface 214 forwards the message to the Authentication Processor 216. The Authentication Processor 216 examines the message sent by the mobile user and creates a session for the mobile device 200. The session may include a byte code message including a URL.

The session is linked to the mobile number of the user. If this same URL link is tried on another mobile number, it doesn't work as the Third-Party System 202 detects that it is another mobile device browser. The Authentication Processor 216 sends the byte code message to the mobile device 200 via the Mobile Interface 214.

The Application handler 210 checks the integrity of the byte code message and forwards the byte code message to the Application Engine 208 for execution. The Application Engine 208 executes the byte code message and extracts the URL link from the message and forwards the link to be displayed on the User Interface 206 of the mobile device200

Once the user clicks the URL link, a dynamic byte code message gets created. The Application Engine 208 creates the dynamic byte code message which includes the details of the mobile device 200 like the technical configurations details and sends it to the Application Handler 210. The Application Handler 210 checks the integrity of the data and forwards the dynamic byte code message to the Third-Party System 202.

The Authentication Processor 216 of the Third-Party System 202 extracts the details of the mobile device 200 from the dynamic byte code message and decides on the version of the MIDlet to be sent to the mobile device 200. The Authentication Processor 216 may store these details in the Database 218 of the Third-Party System 202. The Authentication Processor 216 also decides whether a JAVA application descriptor (JAD) or Manifest file needs to be sent to the mobile device 200. The type of version of the application to be sent depends on the configuration of the user's mobile device 200. Most of the mobile devices 200 are compatible with JAD files, but occasionally, for example, in some Motorola devices, a JAR file is sent by the Third-Party System 202. The Authentication Processor 216 creates an encryption key based on a random seed and a unique key identifier tied to this key. The encryption key and the key identifier are linked to the mobile device 200 of the user. Alternatively, the encryption key and the key identifier may be linked to the mobile number of the user.

The Authentication Processor 216 attaches the encryption key and the unique key identifier into the JAD or Manifest file. The JAD or Manifest file may also contain some configuration attributes of the MIDlet to be installed. This dynamically created JAD or Manifest file is attached into a dynamic byte code response message and sent to the mobile device 200 for execution. The Authentication Processor 216 may store these details in the Database 218 of the Third-Party System 202.

The Application Handler 210 of the mobile device 200 receives the dynamic byte code response message and checks for data integrity and security issues. The Application (which includes the configuration) gets installed in the device 200. The Application Engine 208 may extract and store the key identifier in the persistent data storage i.e. RMS 212. The encryption key is only available in the run-time of the MIDlet application as a system property.

By way of example, on invoking the MIDlet application, all sensitive data entered such as passwords and personal identification numbers including hashed or encrypted values is encrypted with the encryption key and stored persistently in the Record Management System (RMS) 212. This data can be retrieved and used only inside the concerned MIDlet application by decrypting the data using the encryption key. The Application Engine 208 may encrypt/ decrypt the sensitive data with the encryption key and store the encrypted/ decrypted data in the Record Management System (RMS) 212. The encryption key is only available to the MIDlet during its run-time.

The key identifier uniquely identifies the encryption key and it is stored in the RMS 212. Since the encryption key is never stored in the RMS 212, the key identifier provides the application with a way to identify the encryption key which was used for encrypting the data. The absence of a key identifier in the RMS 212 indicates that the persistent data has not been encrypted with any encryption key. The mobile device is any device used for communication over a wireless communication network and includes a mobile phone, a smart phone, a Personal Digital Assistant (PDA) or a pager.

Specific embodiments are described below:

A method of provisioning an application on to a mobile device comprising generating an encryption key based on a mobile device identifier to be used by the application to encrypt and decrypt persistently stored data; placing the encryption key in the application installation file and transmitting the installation file to the mobile device; storing the encryption key on the mobile device to be made available as a system property only to the application during its run time.

Such method comprising generating a key identifier for the encryption key, and placing the key identifier along with the encryption key in the installation file for transmission to the mobile device.

Such method(s) wherein the encryption key and/or the key identifier is placed in the configuration file of the application installation file.

Such method(s) comprising storing the key identifier in the data store of the application on the mobile device.

Such method(s) wherein the configuration file is a Java application descriptor file (JAD) or a manifest file.

Such method(s) wherein the mobile device identifier is the user mobile number or the mobile device number.

Such method(s) wherein the application management system present on the mobile device extracts the encryption key from the configuration file and makes it available to the application in its run time.

Such method(s) wherein the application management system present on the mobile device extracts the key identifier from the configuration file and stores it in the application data store.

Further specific embodiments are described below:

A method of encrypting or decrypting data on a mobile device comprising invoking an application capable of encrypting or decrypting data using an encryption key, the encryption key stored in a location other than the persistent data storage by the application management system of the mobile device and made available only to the application as a system property during application run time, and encrypting the unencrypted data stored on the data store of the application and storing the encrypted data on the data store of the application.

Such method(s) wherein the application includes a key identifier linked to the encryption key and stored in the data store of the application; comprising comparing the key identifier with a key identifier stored in the application configuration file; and using the encryption key to encrypt/decrypt data stored in the data store of the application if the key identifier stored in the application data store and the key identifier stored in the application configuration file match.

Such method(s) wherein the application includes a key identifier linked to the encryption key and stored in the data store of the application; comprising comparing the key identifier with a key identifier stored in the application configuration file; and sending the key identifier stored in the data store of the application and the key identifier stored in the application configuration file to an application provisioning server for validation.

Such method(s) comprising encrypting the encryption key corresponding to the key identifier stored in the data store of the application using the encryption key corresponding to the key identifier stored in the application configuration file, if the key identifier stored in the data store of the application and the key identifier stored in the application configuration file are valid for the mobile device, and sending the encrypted key to the mobile device.

Such method(s) comprising decrypting the encrypted encryption key corresponding to the key identifier stored in the data store of the application and using the decrypted encryption key to decrypt data stored in the data store of the application; and re- encrypting the data stored in the data store of the application using the encryption key corresponding to the key identifier stored in the application configuration file.

Such method(s) comprising replacing the key identifier stored in the data store of the application with the key identifier stored in the application configuration file. Further specific embodiments are described below:

A mobile device application capable of encrypting sensitive data comprising an encryption key to encrypt and decrypt persistently stored data, the encryption key stored in a location other than the persistent data storage by the application management system of the mobile device and made available only to the application as a system property during application run time.

Such method(s) wherein the encryption key is initially provisioned to the application by incorporation in the application configuration file.

Such method(s) wherein the encryption key is stored as a system property on extraction from the configuration file by the application management system of the mobile device.

Such method(s) comprising a key identifier linked to the encryption key, the key identifier persistently stored on the mobile device. Such method(s) wherein the application is signed.

INDUSTRIAL APPLICABILITY

The method and system described offer fool-proof security to the stored contents in the persistent data storage or the application data store as even if data stored in the persistent data storage is obtained by a hacker, such data is rendered useless as the encryption key to decrypt it is not available.

Security breach may also take place by way of an attack on the MIDlet by another un-authorized MIDlet that tries to replace the existing MIDlet and read the persistent data. The method and system prevent such instances as the application is signed, if the installation happens through the JAD. The application signature is stored in the JAD and validated by the mobile device against its certificate at the time of installation. Even if the application is un-signed and an un-authorized application updates it, then also the encryption key would be lost as the system properties would get over-written by the new MIDlet.

The method and system of the invention can be implemented on all user devices and mobile phones across various platforms including, but not limited to Java, Windows Mobile, Google Android, and requires minimal alterations to existing systems for deployment. Additionally the encryption algorithm used may be changed from 3DES to AES or other encryption algorithms.

While specific language has been used to describe the invention, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the system in order to implement the inventive concept as taught herein.

Claims

We claim:

1. A method of provisioning an application on to a mobile device comprising: a. generating an encryption key based on a mobile device identifier to be used by the application to encrypt and decrypt persistently stored data; b. placing the encryption key in the application installation file and transmitting the installation file to the mobile device; c. storing the encryption key on the mobile device to be made available as a system property only to the application during its run time.

2. A method of provisioning an application on to a mobile device as claimed in claim 1 comprising generating a key identifier for the encryption key, and placing the key identifier along with the encryption key in the installation file for transmission to the mobile device.

3. A method of provisioning an application on to a mobile device as claimed in claim 1 or 2 wherein the encryption key and/or the key identifier is placed in the configuration file of the application installation file.

4. A method of provisioning an application on to a mobile device as claimed in claim 2 comprising storing the key identifier in the data store of the application on the mobile device.

5. A method of provisioning an application on to a mobile device as claimed in claim 3 wherein the configuration file is a Java application descriptor file (JAD) or a manifest file.

6. A method of provisioning an application on to a mobile device as claimed in claim 1 wherein the mobile device identifier is the user mobile number or the mobile device number.