FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See section 10 and rule 13)
TITLE OF THE INVENTION


A METHOD AND SYSTEM FOR CLIENT DATA SECURITY
APPLICANT (S)
(a) Name : MCHEK INDIA PAYMENT SYSTEMS PVT.LTD.
(b) Nationality : Indian
(c) Address : A 102 Delphi, Hiranandani Business Park, Powai, Mumbai -76

The invention relates to client data security. In particular, the invention relates to client data security in software enabled 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. Numerous 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 hackery. 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. DETAILED DESCRIPTION
The invention provides for a method and system to encrypt sensitive data stored on a client mobile device. The key employed for encryption of data is not stored on the client database or in the application code.
On provisioning an application to a user, the system generates a unique key a)ong with a unique version that is used to identify the user. The unique key and the unique version is added to the Java Application Descriptor (JAD) /Manifest file of the application and sent to the mobile device. This is installed in the phone and this key is accessible to the Java application during its run time and is not stored persistently in the persistent data storage. The application management system (AMS) present on the mobile device for managing the application receives the JAD or the Manifest attributes. These attributes including the encryption key are made available to the application only during its runtime as system properties.
The user initiates the process by requesting a download of the application on the user mobile device. On receiving the user request a unique 16 byte key and a key-version, which uniquely identifies the user is created and added to the JAD or Manifest file depending on the mode of download.

The key-version is stored in the persistent data storage but the corresponding key, K l, is never stored in the persistent data storage. All sensitive data such as passwords and personal identification numbers including hashed or encrypted values is encrypted with the key Kl and stored persistently in the application. This data can be retrieved and used only inside the application by decrypting the data using the key Kl. As the key Kl is not kept outside the Java run time system, the data encrypted with it is completely safe from any hacking attempts. Even if a hacker gets hold of the persistent data stored on the phone and the decompiled code, he would not be able to decrypt the encrypted persistent data.
The .kev K1 is a 16 hvte value, which will he used as the key in the 3 DES encryption / decryption of the data. Key version is a unique number, which is tied to Kl and also to the mobile number - there by, uniquely identifying the user.
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 sends an SMS with a predefined keyword to the system, the keyword indicating a desire to download an application. The system server creates a session for the user that is linked to the mobile number of the user. With this session information, a dynamic WAP [wireless application protocol] link is sent to the user by the system. If this same WAP link is tried on another browser, it doesn't work as the system server detects that it is another device browser.

On clicking the WAP link, the system server decides on the version of the application to be sent and also decides whether JAD or Java Archive (JAR) file needs to be sent to the client. The type of file to be sent depends on the user handset.
A 16 byte (32 hex characters) key, Kl is created based on a random seed and a unique Key-version tied to this key is also created by the system. The key, Kl and the key-version is linked to the mobile number of the user.
The key Kl and the unique key version are written into the JAD or manifest file. This dynamically updated JAD or manifest is sent to the user mobile device which installs the application on the user device.
On invoking the application, the unigue key version is stored in the persistent data storage of the MIDlet. Once the application is invoked, the key Kl is queried and obtained as an application property. Key Version needs to be stored in RMS as there should be some information related to the key in persistent storage. If the stored and JAD key-versions do not match, we can infer that we cant use Kl to decrypt our data and so our data needs to be migrated to the newer version. For this the client would synchronize up with the server such that the old key is given back to the client in a secure manner so that the data could be migrated.
If the persistent data storage already has some key version stored in it and this is not matching with the key version which is currently there in the JAD or manifest, then the key-version of the persistent data storage and the key-version in the JAD or manifest are sent to the server for validation. The server validates the key-version against the user and migrates the user to the new key if the key-versions were found proper. New key would

be a newer 16 byte key, K.2 which has a different key-version, but tied to the same user(mobile number). This could be considered as update of key for the user.
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 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 Kl (3DES encryption) and this is stored in the client database or the persistent data storage. The personal identification number acts as a gatekeeper to different functionalities within the application. When a user enters a personal identification number that needs to be validated, the stored encrypted value is decrypted using the key K1 and verified.
The method and system described offer fool-proof security to the stored contents in the persistent data storage as even if data is obtained by a hacker, such data is rendered useless as the 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 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 key Kl would be lost as the system properties would get over-written by the new MIDlet.
The system also provides for some additional checks and rules to ensure that the correct keys are being provisioned to the user. If a different key has been provisioned to a user, there are checks in the system to ensure that the fraud is detected as some part of the

key version is tied to the originally intended person and could be identified in the first communication. Key. kl and the version is tied to a mobile number at the server. The version would be sent as part of secure application SMS to the server, as part of any communication. From the SMS mobile number of the sender could be retrieved and could be validated as to whether he is the right person to use the key-verion.
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, BREW, Windows Mobile, Google Android. Apple iPhone, 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.