WO2011030352A2

WO2011030352A2 - System and method for mobile phone resident digital signing and encryption/decryption of sms

Info

Publication number: WO2011030352A2
Application number: PCT/IN2010/000592
Authority: WO
Inventors: Sethi Mohit
Original assignee: 3I Infotech Consumer Services Ltd.
Priority date: 2009-09-11
Filing date: 2010-09-06
Publication date: 2011-03-17
Also published as: ZA201006435B; WO2011030352A3; AP2010005394A0

Abstract

The system and method provide for a mobile phone resident application for symmetric and asymmetric cryptographic operations including digital signing of SMS and encryption/decryption of SMS without the use of SIM or any specialized hardware crypto module. The system also provides a method for secure generation of Keys using novel multipart seed generator within the mobile phone device. The system also provides a method to securely store the Keys using dual layers of encryption technique.

Description

SYSTEM AND METHOD F MOJIJLE PHONE RESIDENT DIGITAL SIGNING AND ENCRYPTION/DECRYPTION OF SMS

TECHNICAL FIELD OF THE INVENTION

001— This invention, is.made in the field of Public Key Infrastructure whereby digital signing and encryption/decryption of confidential messages is enabled through the use of key pairs generated by the user Personal Trusted Device such as mobile phone device, where the public key is made available to the receiver to encrypt the message or verify signed message and the private key is retained by the sender to decrypt/ sign the message. The invention relates to technology enabling exchange of confidential data, generation of digital signatures and secure generation and storage of RSA Keys in a Personal Trusted Device such as Mobile Phones. The Public Key Infrastructure provides the basis for 2nd Factor authentication for e-transactions such as banking and e- commerce which require authentication and validation of the identity of persons -accessing -the-server— through-their— computet_as, _wejj as sending of confidential messages to users on their mobile phone devices.

GLOSSARY

002 A PTD is a small device belonging to a single person to enable trusted operations with "oth^r^{^}entities ^'in an lnformation~Technology-&-eommunication infrastructure and includes mobile phones, Personal Digital Assistants, multimedia mobile phones, laptops, palmtops etc. For the performance of this invention, the PTD should be enabled with SMS capabilities

P T/IN2010/000592

2

BACK GROUND OF THE INVENTION

003 In the prior art, applications enabling financial and non-financial confidential transactions including key generation, storage, and encryption/decryption were based on the native SI toolkit applications or Wireless Internet Browser (WIB). The drawback in the prior art is that the SIM card provider or service provider participates in the PKI process enabled on the mobile phone thereby potentially compromising the confidentiality of the process. Moreover, a user wishing to change his service provider would have to undertake steps to authenticate himself afresh with the Certifying Authority thereby reducing autonomous functioning of the device with regard to the invention enablement. -

004 Another drawback in the prior art is that there is only a single layer of security provided for the keys and the confidential messages. Yet another drawback in the prior art is that it cannot provide two-Factor Authorization which is essential for digital signing and non-repudiation required for electronic financial transactions such as banking, trading or card payment.

005 Yet another drawback of the prior art is that it is more expensive to implement than the current invention. The current implementations of Digital Signatures provide security and non-repudiation, but cannot be scaled up for mass usage due to high costs ^"involved^_in-acquiring--and-maintaining-the-devices required by the user. For instance Smart Cards or USB Tokens used to store private keys are expensive and the scope of such devices is limited to the use of digital signatures only. Moreover, the holder of such devices needs to take extra care of such devices to prevent them from being misused or compromised. The smart card or USB token requires the installation of specific licensed software such as eToken Run time Environment, eToken PKCS11 DLL and CSP (Cryptographic Service Provider), SETEC CSP and PKCS11 DLL, GI-DE Star

COS CSP and PKCS llin the computer system where they intend to use them. It is another disadvantage of the prior art that multiple operating systems and browsers fail to adhere to a common standard for Digital Signature applications, involving the development of applications for multiple smart cards or token types. 006 Yet another drawback in the_^ prior art is the susceptibility of computer systems to viruses and/ or malicious code which can take control of the operating system and generate or tag signatures to unintended documents and cause data security to be compromised. Moreover, popular key tracker works can also be used by an intruder to detect the PIN or password of the token. Soft tokens too are prone to copying and compromise by malicious code or another person. Yet another drawback of the prior art is that it is not easy to achieve 'what-you-see-is- what-you-sign' in the digital world except when using trustworthy encapsulated systems with limited functions and absolute GUI control. In the invention, user will be able to see the details of the data which they are going to sign. The actual text of the displayed financial message is hashed for generation of digital signature. Also user can see the distinct relationship between the data that have seen in the PC and the mobile screen thus providing them more trust in the data requested for signing. The Ul/GUI of the E W midlet is unique and cannot be accessed by any other applications on the device thus providing absolute control.

SUMMARY

008 The enablement of PKI operations in a PTD such as a mobile phone has to address multiple technical challenges due to the inherent constraints of such mobile devices due to the market compulsion to ensure small size, low weight, mobility and personalisation. Some of the key challenges are:

009 Device Processing Constraints & Device OS Limitations: The embedded processor and operating system in mobile phones has low processing capability when compared to the processor and operating systems present in personal computers and PDA's. Moreover, the operating system residing in the mobile device varies from device to device based on make and model. The operating system does not provide a run time environment where generic PC based applications can be deployed these will require that applications should be developed for a particular device with a particular operating system. However, this constraint has been reduced to the innovation of virtual machines such as Dalvik Virtual Machine, Java Virtual machine, Lily Virtual Machine, Oracle Virtual Machine etc.

0010 File System Security Constraints: Mobile phones and other PTD suffer from security constraints in that the J2ME application is entirely in control of the underlying Virtual Machine and the manufacturer's implementation in terms of location of the files in the device operating system, leaving open the possibility thaPseirfe 'extraction tools can be used to retrieve, read and manipulate files stored in the device.

0011 Randomness Generator Constraints: Mobile devices and other PTDs lack processing power to generate secure random numbers of unique and high randomness and to generate secure key pairs using algorithms for public key cryptography such as RSA or ECDSA, which may result in similar or identical key pairs in two independent devices.

0012 The invention comprises of two core components which are the EMW Midlet (J2ME application residing on the mobile device) and the EMW Server (server component) with SMS as the communication channel. The description of the invention and the method by which the challenges are addressed is given in the provisional specification section. DESCRIPTION OF DRAWING

0013 FIGURE 1: Component architecture of the EMW Midlet Suite

and the EMW server component

Component 1: Mobile Client - EMW Midlet: Core J2ME application running on KVM in mobile device with minimum MIDP 2.0 and CLDC 1.0 supporting JSR120/JSR205. Application requires around 150 KB memory.

Component 2: Private Keys: RSA keys in preferred embodiment generated and stored in the EMW Application, with specified size of private exponent and public modulus. The keys are generated by the 9A and stored securely using 13 and 3. The public exponents of the public keys are not stored in any persistent storage as the value of the public exponent is fixed to 0X010001 in HEX Value or 65537 in decimal.

Component 3: Dual Layer of Protection of Keys: Keys are first encrypted using the pin/password associated with the private key first and secondly with the pin/password associated with the application login pin. The encryption mechanism used is password based encryption method referred- as-PKCS12 standard. The Encryption using pin refers to the symmetric keys derived from the pin(s) using salt and padding. 3 uses 13 to perform this dual layer protection process.

Component 4: Binary Message Listener: Listens for an incoming binary message at the target device with the specified port number, in the preferred embodiment port number 9001 and collects and forwards the message to component 9 if the message confirms to a binary message with complete message as a 8 BIT encoding by checking the instance of the incoming message using the WMA 120/205 API's. 4 runs on a synchronized thread model, hence one or more events of 4 can be executed if there are multiple messages arriving at a concurrent event. '4' doesn't process any validation to the incoming messages in terms of types of allowed messages or validation of message senders. If the application is not running in the target device then the AMS (Application Management System of the JVM) invokes the listener and the application comes to an activation state. The device native system combines segmented message before invoking the binary message listener. Once the message(s) is retrieved by 4, the message is no more available in the java inbox. Java Inbox refers to the native implementation of the mobile JVM which stores the message until the appropriate application retrieves the message. Here appropriate message refers to the EMW Midlet 1 for which the message is destined and addressed for.

Once message(s) is retrieved by 4, 4 triggers 9 by calling the appropriate method referring to 9 and the life cycle of 4 for the messages in question is over. 4 runs on a synchronized thread model, hence one or more events of 4 can be executed if there are multiple messages ^arriving at a concurrent event. '4' doesn't process any validation to the incoming messages in terms of types of allowed messages or validation of message senders. The only validation which is performed by 4 is to check if the incoming message is a binary message or not.

Component 5: Binary Message Dispatcher: Sends a binary message to the server or to the other mobile device having the 1 installed and configured in it. '5' is either invoked by 14 or 11 for sending user messages, response to admin message or PKI messages.

'User messages' refers to messages used to exchange public keys between two peers or any messages which is not related to any PKI operation or admin operation, 'response to admin messages' refers to the response generated by the 1 for a admin command received and executed by 1 and which requires a response to be sent to 26, 'PKI Messages' refers to the crypto messages generated by l for any of the PKI operations supported by 1 which includes

A. Sending certificate request or activate key request message

B. Response to a signature request

C. Response-to-decipher-and.acknowledgement.request

5 D. Sending Confidential Message-to another peer

E. Sending Signed Message to another Peer

F. Sending Activation Request to the server '26'.

5 runs on a single synchronized instance. In an instance a message is destined to be sent,0 14,11 or 9A calls the reference method associated with 5 and passes the params which includes the binary data to be sent and destination number address for which the message is addressed too. 5 uses the WMA 1.0 or 2.0 available in JVM implementation and make an attempt to send the message. If due to some reason, 5 is unable to send the message, 5 throws an exception to the component which is calling 5 for a request to send the message.5 Before sending message 5 also checks for the format of the destination number and throw an exception if the destination number is not formatted or not proper.

5 take precedent to any other event or alarm that might be executed in 1 which can be an alert for an incoming message or an alert for a message in queue. All such alert or operations are performed ^~when~5 execution-processes is completed either successfully or0 with an error. 5 also have a fixed persistent storage area dedicated to it. This is used by 5 for storing the last sent message and which was successfully executed. When a message sending request is arrived at 5, 5 compared the message data with the stored data. In an event the requested data matches with the stored binary data, '5' invokes 14 for taking user consent for sending the message which is already sent. This is done for avoiding resending of similar 5 messages due to user error or any error generated by the 1. The persistent storage area used by 5 is emptied when the application restarts. Component 6: Secure Random Mixer Component: This component performs the unique process of generating-the-complex-seed-and-random number using which the RSA Keys will be generated. It uses a proprietary algorithm to take random inputs from the mobile device and the random seed received from 26 and 17 to generate a very high degree random number which becomes the seed for generation of RSA Keys ensuring uniqueness in the keys generated by the device or sets of device and compensates for the low processing power of constrained mobile device which fails to generate high degree of random number. '6' is invoked by 9A in the process of generation of RSA Keys.

In the process of invocation, 9A provides 16 bytes of random seed which is generated using the mobile device hardware and a reference to the server seed stored in the persistent storage of the mobile device. During the activation stage of the mobile device, the 26 EMW Server sends a admin command to 1 with a series of seeds generated by 26 which are then stored in the persistent storage of the mobile device. 6 now fetched the server seed using the reference provided from the persistent storage and runs a algorithm to generate a output seed of 16 bytes where the inputs to the algorithm is 16 bytes of seed generated by the 9A and 16 bytes of server seed extracted from persistent storage. The newly generated seed is taken over by 9A for generating high randomness random number. Once the process of generating seed is complete, 6 puts a flag on the server seed which indicates that the seed is used. In an event 6 receives a^~req^'uest from 9A pointing to a server seed which is found to be flagged as used, 6 responds with an error to 9A indicating invalid reference to server seed material.

Component 7: Post Integrity Check: Post integrity check is process in which the application scans the integrity of the persistent storage using logics and proprietary algorithms to detect any external changes to the storage data by an event. The event can be triggered by a person having intention to crack the persistent storage of the application or to extract the sensitive information from the persistent storage. Any such attempt which can be success or failure can temper the integrity of the persistent file system. If such a scenario is detected the 7 ^" detects the type of change-wow either-it is application error, event or an external entity generated event. Application Error Event refers to the process in which the application 1 in a case where. it failed to- write or-update data in the storage. If an external event process is detected 7 sends the warning signal to the 10 for action.

Component 8: JVM with MIDP 2.0 Specs: This refers to the JVM, referred to as Kilo Virtual Machine (KVM) in mobile phones, which is residing in the target mobile device. MIDP 2.0 refers to the profile which should be at least supported by 8 for the installation of 1 in the device.

Component 9: Message Type Detector. Access Control Process where the incoming message is classified based on its type, which is a single byte header of the incoming message present in the first byte of the incoming message. The message types can have values ranging from 0x00 to OxFF. Here the lower nibble is the message type and higher nibble is reserved for future use. The higher nibble for certain types of messages is used to provide some extra information regarding the processing environment request for the incoming message. For Example an incoming message with message type 0X00 indicates that the message is intended for decipher and acknowledgement signing whereas an incoming message with message type 0X20 implies that the message is a confidential message meant for only for decipher and no signed acknowledgement is needed to be signed and sent back to the sender of the message. If the message- seems- to be-of-unknown- message type_the message is discarded. The Access -control-process-checks-if-a-part4cular-message-type_-is-.allowed to be dispatched from a particular recipient.

'9' is invoked by 4 in the event of 1 receiving a binary message. In this process the complete binary message is dispatched to '9' by 4 for further processing.' 9' checks the message type and verifies that it is a valid message type supported by 1. If the type of message is not supported than the message is discarded and 14 is called by 9 with the exception code in which case 14 informs the user that the message received is an invalid message and the address of the originator of the message is displayed. The codes for all supported message types in 1 may be in software code, or present in the persistent storage in a dedicated record store.

If the message type is valid message type, then '9' checks if the complete binary message is formatted according to the requirement of the message type present in the message. If the message format is invalid 9 informs 14 about the invalid message with an exception code. If the message type and message-format validations are passed, then '9' checks the access control list from the appropriate record store to verify if a particular message type is allowed from a particular sender mobile number. Peer to Peer messages do not require any access control checks but messages with particular sets of message types are needed to be validated against the access control list, tf a message is found to have an access control requirement 9 may trigger 13 for checking the MAC validation of the message. MAC validation of message implies that the incoming message have a MAC which is needed to be verified using MAC key of the sender of the message. MAC validation is not necessary for all access controlled types of messages and this depends on the implementation.

If all validation (s) is passed and message type doesn't belong to the admin command type, 9 Stores the message the persistent storage and the user is alerted of a new incoming message using 14. The life cycle of 9 now ends. If all validations are passed and the message type belongs to admin command type, '11' (Admin Command Listener and Invocation Component) is invoked and the message is passed to 11 for further processing. Any user alert if any required to be provided to the user is now handled by 11 and the process of 9 now terminates. 9 runs on a single thread synchronized code which implies that in all scenarios '9' will process only a single message at a time.

Component 9A. PKI Engine and Validation Service: The 9A is the core PKI engine of 1. 9A runs using the light weight crypto API provided by proprietary software for J2ME Enabled devices. 9A is responsible for all SA operation which includes generation of keys, RSA Encryption and decryption, Digital Signature and verification services. 9A can be triggered by either 14 or 11 for performing any asymmetric key cryptography tasks. The reference to the process and the reference data are passed as a parameter to 9A using its calling method by 14 or 11.

Reference to the process can be a request to encipher, decipher, sign or verify signature processes. Reference data implies the data which is to be processed and also the asymmetric key data or digital certificates, the reference data can be passed completely using the called "method or a reference-to-the-pointer-of-the-data-from-the-secured persistence storage can be provided. If the reference to the pointer to the persistent storage is provided then 9A calls the "13' global objects to fetch the relevant data from the secured persistent storage. The application pin and certificate pin (private key pin) validations are not performed by 9A but they are handled by 13. Certain operations request can also have a pointer to the secure storage where the result computed by 9A is needed to be stored which are request to generate RSA Keys and request for calculation of RSA MACS.

Component 10: Self Destruction of Keys and Data Engine: 10 is a process which performs ZEROIZATION of sensitive keys which are RSA keys and AES keys in the system. The process can also be configured to delete the entire persistent storage from the mobile device. The process can be triggered by either 7 or 11. 11 can instruct 10 for the process in an event a destruction command is received by 11 in 1 from 26.

Once '10' is activated completes^~the^~process,-the key datum or the entire persistent storage is destructed based on request made by the calling object. After performing the operation, 10 writes a unique data in the persistent storage which will enable 14 to understand the current environment of 1 in the mobile device and subsequently any user activity performed using 14 will alert the useTthat then da ^ldestructed due to cited reason and user life cycle terminates and the 1- exits. ···

Since, the

hjghly destructive, the feature can be enabled or disabled in 1 during loading and installation process of 1 based on defined scope of the "application in the.desired:operating-_environment. Before starting the operation of cleaning the keys and and/or persistent storage, 10 writes a special unique data in the persistent storage at a reserved record store. Assuming the application is terminated in the process of cleaning data due to user consent or device error, in the event when 1 is restarted, 14 reads the persistent storage and detects that a admin operation is pending and transfers the control to the 11 which in turn passes the control to 10 for completing the pending tasks. Once the operation of cleaning up of datum is complete, 10 changes the special unique data to a value which will enable 1 and 14 to understand that the application data is deleted.

There is a difference in cleaning the keys and other details in secured persistent storage. The key data is first ZEROIZED. This implies that instead of deleting the persistent object .. assignment from the_application,_10-first_writes 0X00-in the entire area where key data is stored. For example key A is stored in record store A in index 1 with starting location 0 to — 128rthen^0^r5renters^"0X00^"fro^^{^} 10 deletes the record id 1 from the record store A. '10* is called by 7 or 11 using the reference method associated with 10. In this process the 7 and 11 passes input parameters to the 10 invoking method which includes the information regarding reason for the operation in bytes value and the data to be erased from l's persistent storage. Data can is referenced using a byte value indicator byte. The interpretation of the byte value can be deletion of only RSA Keys data, deletion of RSA Key data and Application Keys, deletion of complete data.

Component 11: Admin Command Listener and Invocation: Command processor which executes commands received from 26 in a manner which resembles a command listener in a smart card device. The various commands which can be processed by 11 are install certificate, register new server address with security settings, disable server, ZEROIZATION command, update application, get target device environment, and send error information, patch application and other admin commands. Ί is invoked by 9 in an event a binary message is received by 9 which is having a message type as admin command type. As soon as 11 starts processing an admin command it writes a specific data in the persistent storage in its assigned record store which will enforce a pending task flag in 1 and this task will take priority over all the processes performed by 1. Once the operation is complete '11' removed the specific data from the persistent storage to ensure that normal operation can now be carried. In the event '11' is invoked by 9, 9 calls the calling method assigned for 11 and passes the entire incoming binary message to 11 for execution.

Based on the command type, '11' can call 14 for a user action if required. Where in a new server addresses are required to be added in the system or certain server addresses are needed to be blacklisted or removed, '11' will call 12 for performing the required task. Component 12: Message Sender(s) Validation /Management Engine: 12 is a process where the message sender's validation takes place. '12' is used by 9 or 11 for either authentication of the sender of the message or for adding an authentication entry for a new message sender. 12 has a dedicated area- reserved in the form of record store where lists of trusted servers are maintained and their MAC keys and their associated security permissions allowed in the context of the applications. 26 MAC Key is loaded in the 1 in the process of activation of the application. Any admin command sent by 26 to 1 should also have the MAC appended to it. 12 verify the MAC of such messages.

For example 26 send a binary message to 1 for adding a trusted server entry where server is referred as B and the B's address is BBBBBB. The admin command will contain the information related to the process request including B's description, security level allowed, address BBBBB and B's MAC and finally the entre command's MAC will be appended to the message by 26. Now 26 verify the MAC of the admin message using MAC key of 26 and if verification is successful adds the entries into the allocated persistent storage. " '12'^" manages ^~a^~cdmplete mahagement^~~engi e~f0r^~ trusted server and their associated security levels associated with them. Security levels imply the various types of messages which can be processed by 1 in an event they are received from a server. 9 can call 12 only for verification of MAC while 11 can call 12 for any operations supported by 12.

Component 13: Symmetric AES Data Storage Processor: 13 is a component process which enables 1 to store data and retrieve data from the secured persistent storage. 13 used the 15 keys to store and retrieve data. All the persistent storages are encrypted using the application AES key. The process remains same for entire persistent storage except for the 3 where 13 runs the logic twice as explained in 3's description.

'13' is a global object derived from a class which is initiated when the application is started which implies 13's object is initialized by 14 when the application 1 starts. All the other components use this global object to read and write data in the secured persistent storage. '13' runs in singleton mode ensuring access to persistent storage is only through a single implementation.

Apart from storing and writing of data in the secured persistent storage, '13' is also used to

This implies that the initialization of the '13' requires the login pin as an input. If the pin validation is failed '13' global object failed to get initialized and 14 are sent the error code.

The first activation and initialization of 13 is performed by 14 during the starting of the application where the login pin is taken by 14 and passed to 13 for verification and initialization. W 201

12

Component 14: User Interface and Mopping: 14 is the core GUI component of 1. The process enables the user of 1 to enable process and functions with 1. 14 uses the core GUI components API of J2 E to generate a GUI and Menu structure. '14' represent's the window to the application for the user. '14' is invoked by the constructor of the l's midlet class. When '14' runs for the first time during the start of the application and there is no admin command entry in the persistent storage with priority level byte "indicating high & login not required", it detects if 13's object is initialized or not. If the value of 13's object is null, 14 automatically request the user to authenticate by providing the pin used as login pin to the application. Upon receiving the pin, the pin is passed to 13 for verification and initialization of 13.

When '14' runs for the first time during the start of the application and there is a admin command entry in the persistent storage with priority level byte "indicating high & login not required", it activates the 11 method and waits for a request to proceed further from 11. This happens in the case of a pending admin task with very high priority like patch update or data destruction. Once 11 recalls admin method, 14 performs the tasks as described from beginning of 14's description.

Upon initialization of 13, '14' scans for the entire persistent storage data and provides user with option to read-new-messages-or-old-messages for processing. If there is admin command in waiting with priority set as "LOGIN" then the user screen is not visible to user until the admin process is completed and the user is alerted that the admin process is in process "Please wait Signal".

The operation of now continues as per the navigation of menu's by user in 14. '14' does not scan for admin command process in persistent storage unless a trigger is made by 9 or 11 to 14 for a new activity or message received signal. Component 15: APP Keys: An application key refers to the AES keys used by 1 for user login verification and reading and writing the persistent storage data. Figure 2 and Figure 3 describes the process of generation of APP keys and storage of APP keys in the secured persistent storage system. Figure 3 also defines the process of using the APP keys to store and retrieve data from persistent storage using 13. Component 16: Certificate Authority Connection Manager: provides connectivity and processing with the Certifying Authority Server for generation of certificates and for fetching CRL's.

Component 17: PKI Engine and Validation Service: This is the core PKI engine responsible for validation of digital signatures received from 1 and also for verification of certificate request or key pair activation request by 1. In the process of encoding or decoding the binary message 26 used 17 for generating the SMS data.

Component 18: Binary Message Listener: This process component listens for binary message from any of 1 residing in a mobile device.

Component 19: Binary Message Dispatcher: This component process is responsible for sending binary SMS with port address to the target mobile device where 1 is residing.

Component 20: Service^' Prbliders Listene Web^'Service (Secured Processor): This software process is the secured asynchronous web service module which provides the gateway for the service providers to interact with 26 and

Component 21: OCSP Client: 21 is a software process which is responsible for fetching the certificate status of a certificate which is in process for an operation by the 25 and 17 for performing a PKI task.

Component 22: CRL Database: Maintains an updated CRL for all the CA's incorporated and supported by the system.

Component 23: Registration Database: The 23 maintains the registration details related to the user using 1 in a mobile device. The details include the user details, mobile device network identification number along with device details which includes the handset make and model and IMEI number.

Component 24: Certificate Database: 24 contain all the certificates associated with the RSA keys in 1.

Component 25: Transaction Database: This contain and maintains all the transactions being performed or in process by the 20 for a particular 1. The transactions can be 2 FA or request to send confidential data with acknowledgement request.

Component 26: EMW Server:- The- EMW- Server..(e-Mudhra Mobile Validation and Verification) server is the core server which constitutes of other sub component processes and is responsible for activation and interacting with the 1 EMW Midlet. 1 is initiated and configured by 26.

Transaction Messages and Types

The Transaction Messages are divided into two categories which are: a. Client Server Messaging (EMW Midlet - EMW Server)

1. Server to Client I. Confidential and Acknowledgement Request Message

II. Fund Transfer Signature Request

III. Certificate Request Response (Certificate)

IV. Admin Controlled Messages

2. Client to Server

I. Acknowledgement Signed Response

II. Signed Transaction Response

III. Midlet Activation Request

IV. Certificate Request Message

b. Peer to Peer Messaging (EMW Mobile - EMW Mobile)

I. Send Confidential Message

II. Send Signed Message

0014 FIGURE 2: One time process of generation of 128 bit AES Key and the generation of 128 bit application AES Key Parameter

0015 FIGURE 3: Process of generation of application key using the IMEI/IMSI number

0016 FIGURE 4: Process of Secure RSA Key Pair generator mechanism and storage of keys using dual layer of encryption security

COMPLETE SPECIFICATION

0017 The invention provides for a system and method for Personal Trusted Device Resident Digital Signing and encryption/decryption of SMS and auto-invocation of the application in the PTD on receipt of port- based SMS.

0018 The invention comprises a software application (EMW Midlet)whose core features include secure generation of asymmetrical keys with the multipart random seed generated in the Personal Trusted Device and secure storage of the keys so generated using dual layer of security being PIN based encryption and encryption of token file using a unique symmetric application key. The software application would be bound to the Personal Trusted Device. The Personal Trusted Device herein could be a mobile phone, a multimedia mobile phone, a Personal Digital Assistant or any small version of the personal computer such as palmtop or laptop enabled with SMS capabilities.

0019 Further, the invention comprises a server application (EMW server), whose core features include the generation of port based SMS, validation of signed messages received from ^"PTD application, encryption or decryption of messages from PTD application and providing interface for relying party applications.

0020 The invention also provides a higher level 2 Factor Authentication (TFA) and non- repudiation where a Digital Signature Certificate is issued by an authorised public Certifying Authority both of which are necessary in order to engage in Financial transactions such as but not restricted to Banking, Share trading or card payment, where the origin of the transactions could be on a web-based application or another PTD based application; receipt of access documents such as travel tickets, airline and hotel reservation, booking and confirmation.

0021 Further, autonomy from SIM-based operation ensures that the user of the PTD can engage in confidential transactions without compromising security such as but not restricted to receipt of confidential messages from third party systems such as but not restricted to ATM PINs, internet banking logins, transactions passwords and confidential reportsThis provides added stability and security to the system as the network provider or service provider does not have to participate in the operation of the invention. This also ensures that changing of the SIM or network does not disrupt the operation of the invention and preserves autonomy of use and digital ID management where authentication is required to access certain privileges such as health care or institutions requiring authentication of ID. The TPD, thus enabled can be plugged into different host devices for encrypted content usage on different platform and can also be connected to a secure network using authentication derived from the invention.

0022 The EMW MIDIet (fig. 1) interacting with the EMW server form the core of the invention. Components 4 and 5 are the Binary Message Listener and dispatcher services. For multiple incoming Binary SMS the queuing is managed by the application in accordance with the AMS (Application Management System). Whenever an incoming message is received by the device with the port address 9001, the message is forwarded by the AMS to the EMW MIDIet. The MIDIet validates the origin of the message using component 12 after the application key is used to encrypt the message and store it in the persistent storage. If the application is not active when the message arrives, then the push registry API of the operating system invokes the application and alerts the user, giving him the option of opening the application immediately or to not open the application at that time. When the application is opened either by accepting the prompt to open the application, of if the application is opened by user manually later, the user is prompted-to enter the master PIN, the application key is generated in I and now causes the queued messages to be encrypted and placed in persistent storage. The invention enables transmission, exchange, retrieval of encrypted data stored in the mobile device using encryption/decryption of the communication preventing interception by third parties. The invention allows the user to file tenders, enter into financial transactions and receive documents such as tickets for travel or authentication for entry into buildings or institutions.

0023 One implementation of the system and device described, uses SMS present in any mobile device present in the market today and is a globally accepted standard among various mobile communication standards (GSM/CDMA TDMA/UMTS/WCDMA etc). The capacity of one SMS message is 256 Bytes in which 116 Bytes are consumed by the SS7 Layer in the transport layer which contains the GSM headers. The remaining 140 bytes are available to the user for exchange of message. In practice the mobile device packs the 140X8bit encoding into 160X7bit encoding to facilitate more text in the message. In the method described in the invention 140X8bit encoding shall be used. In the implementation, normal SMS shall be enhanced to port based SMS, wherein SMS's are addressed to a particular port. The EMW MIDIet registers port number 9001 with the mobile equipment in the process of installation. Henceforth any incoming message with port number 9001 is forwarded to the EMW MIDIet instead of the native inbox of mobile device.

0024 The processing constraint challenges are addressed in the present device and method using an application development based on the PTD or mobile device operating system which can run on devices where the specific operating system, such as but not restricted to JVM, DVM, Oracle VM or Lily VM exists. The processing constraint is addressed by writing the code in a manner that it requires lesser processing power in terms of the API used to develop the application. More and more cryptographic operations are performed using software codes written in bytes processing rather than integer or high order data type processing. Number of objects and variables declared and used are kept at bare minimum and reuse pattern is used to maximum. Component 8 is the Virtual Machine, such as, but not restricted to, JVM (KVM) or DVM on which the application is running. The MIDIet may reside in the operator domain or manufacturer domain based on the digital signature on the MIDIet. Component -tl(Admin Command Listener and Invocation) is the module within the MIDIet which gets activated when the incoming binary message is an administrative message for storage of certificates, changing of menu's, storing of secure random data or message to destruct the application data and key data. The component 11 is also used by the EMW server to add trusted server address (mobile number) in the MIDIet with their associated permissions. The command can also activate a second server with permissions to send requests or confidential messages. Component 14 is the user interface and mapping unit which provides the user with an interactive GUI for performing actions which includes viewing incoming messages, decryption of confidential messages and encryption of messages. Component 14 also allows user to perform admin tasks like pin management, certificate details viewing and generation of certificate request and viewing of transaction logs.

0025 The security constraint on PTD or mobile devices is addressed in a novel and innovative manner. The entire persistent storage in the device generated and used by 1 is encrypted using 16 bytes AES key and the RSA or ECDSA Keys are dual encrypted

^"■ using twTTdiffeTel ^ overhead and processing time in the application but refinements to the highest extent were performed to maintain a decent user experience in the application usage. The algorithm and padding used in the encryption uses a proprietary mechanism, such as but not restricted to legion of bouncy castle cryptographic service provider, using which the data is scattered in such a way that the decrypted data doesn't have zero padding bytes in it. This also ensures that an intruder or attacker will not be able to know if he/she succeeded in deciphering the data in the persistent storage hence making the compromise of persistent data highly impossible. Component 10 is the self destruction module which can perform zeroization of persistent data and key data in the event a fault is detected in the integrity check or the administrative message is received by the server for self destruction. Also to thwart any intentional user making an attempt to generate the AES key using the PIN, an extra protection mechanism is involved as described in Figure 2. The actual AES key used to process the persistent storage is system generated and not derived from user pin. Hence a knowledgeable attacker getting to know the user pin won't have any knowledge of the AES key using which the actual data is encrypted.

0026 To address the issue of constraints in generating random numbers, 1 and 26 used the proprietary logic of random mixer using the 6. The process involves a prop algorithm which used the random generated by the device and random generated by the server to generate a very high degree of random number which will be used for generating the RSA/ECDSA Keys by 1. The 6 algorithm ensures that the randomness generated is very high. Component 6 is the secure random mixer component which maintains logic for generating the random for key generation by using the random generated by the device and the random generated by the server. This is required as the device randomness generator can be limited in certain devices as they lack generation of randomness using noise and they completely rely on the system time.

DESCRIPTION OF PRESENTLY PREFERRED EMBODIMENTS

In one embodiment of this invention, a mobile phone device is used as the PTD with embedded JVM operating system with MIDP 2.0 profile and support for either JSR 120 or JSR 205 API, running the EMW MIDIet suite as a .jar application file. The device is a standard non-windows mobile device with displavabie screen and key pad which supports numeric and alphanumeric input and an alert facility for new incoming message.lThe.EMVV; server-application (software) is installed in a server which has Windows 2003 operating system with MySQL database. The hardware of the server box could be any server class configuration (preferably dual or quod core dual processor boxes). Once the-applieation is installed in the target mobile device, the user opens the MIDIet application and the initialization of the MIDIet begins.

When the application is started the first time, the MIDIet detects that the security data is not yet generated and automatically invokes the first time PIN/password registration menu and the user is asked to input the admin PIN twice. The admin AES 128 Bit Key is generated in runtime using the PKCS12 standard which includes salt and PIN data as input. There is a parallel process running in which the system generates the application AES Key parameters created using pre-calculated random number and digest (SHA1) of random and parameters. The flow is described in the figure 2. The. security, data is now stored in the persistent storage in the user record store and the user is asked to input PJN/password again to enter into the application. This data is stored in the first record ID of the user record store. The admin AES Key is generated at run time using user entered PIN and is not stored in the persistent storage: If the~integrity of the security data is verified by verifying the SHA1 digest of the nner components, the user is granted access to the MIDIet application. The application key parameter is now in memory and the admin key is nullified to thwart any memory attacks. All the persistent storage apart from the security data is encrypted using the application key. The application key is an AES Key which is generated and derived at run time using the combination of application key parameters and the IMEI or IMSI Number of mobile device using a proprietary algorithm. The process of generation of application AES key is described in the figure s.

0029 The user opens the EMW.midlet suite and selects the options to generate key pair .,and_certificate_request._The-user-is-asked-to-enter-the PIN and confirmation PIN which is going to protect the private key. From figure 1, component 9A generates the secure random and interacts with component 6 to generate a high randomness secure random using ~the~server generated random. Another cryptographic service provider API is used to generate a Key Pair using the high randomness random number. The Key pairs are embedded inside a new security data object as described in figure 2. The security object is protected using the certificate access key which can be derived from private key pin provided by the user.

The security object is re-encrypted using the application key by Component 13 in figure 1 and stored in the persistent storage. Before the data is stored in the p^er^ten^storape component jMJn-figure l-generates- a PKCSIO compatible certificate request BINARY SMS which is intended to be sent to the EMW

Server.

0030 Upon receipt of a request by the EMW Server, component 26 from figure 1 detects the message type to be a certificate request message and triggers the component 23 registration database for validation and processing request.

Component 23 validate the registration details of the client device using the unique mobile number. Component 23 then validates if an entry with the same public key exists in the component 24 certificate database. If all validations are passed then the request is stored in the,EMW-Server database. The key se. The user now

application) using a personal computer. User clicks the link to generate certificate from certificate request. The component 16 gets invoked and allows the user to interact with a Certifying Authority and generate a certificate (in case a Public Certificate by a

the certificate to his/her mobile device, other PTD or specified email address. Component 16 updates the components 24 and 25 with the certificate generated and the transaction information. The binary SMS is received by the EMW mobile device. Component 4 receive the message and forward it to component 9 where the message type is decoded and the access control is verified. The component 9A PKI Engine finds the key number and requests the component 13 to store the certificate details in the persistent storage. If the user is not logged in, the user is alerted to provide the master pin followed by which the application key is generated which is used by the component 13 to store the certificate details into the persistent stot^ the status of the key pair associated with the certificate to active state. Now the certificate and associated key pairs are ready for use in transaction of messages either to the

— elien serverWpeertirpeer

0031 Messaging Life Cycle Descriotion^ here-a service-provide intends to get data signed by the enabled device, he/she must send a request to the EMW server web service which, being asynchronous in nature, generates and sends an acknowledgement number.The message sent by the service provider to the EMVV server comprises of the data to be singed or (and) acknowledgement with the mobile number of the intended recipient. The message may also includes extra information like user name, email address etc for validation purposes.

0032 When an incoming message is received by the EMW server through component 20, the message integrity is first verified by component 26 followed by which components 23 and 24 are queried for the EMW mobile user registration status and certificate status. If the all initial validations are passed, then an acknowledgement number is generated and sent to the calling service provider. The link between the Service Provider application (3rd party application) and EMW Server is now disconnected. If the initial validation fails then the EMW server responds to the Service Provider application with the message "Invalid EMW User" and terminates the connection. The process of generating the binary SMS now begins and the response from the EMW mobile will be validated. In the time period between generation of SMS and receipt of response, if the Service Provider request for the status of the acknowledgement number than the EMW Web Service responds with either of the following responses: i. In Process ii. Time Out iii. User Terminated Operation

0033 Based on the incoming request, component 26 generates the Binary SMS to be sent to the mobile device. Components 24 and 25 are used to encrypt the message if required (confidential message). The data which is to be signed by the mobile user (Acknowledgement Data or Fund Transfer Data) is stored in the component 17 P I validation engine database for processing at latter stage for validation purposes. The Key number associated with the user device is added to the SMS data and the Message Type is added to the SMS data. The formatted Binary SMS is sent to component 19 for sending the Binary SMS to the intended user. The Timer process starts in the server which calculates the maximum time before which if the response is not received, the server will discard the response as "Time Out". The formatted binary SMS is received by the PTD device enabled with EMW MIDIet. The AMS of the device redirects the port-based SMS to the EMW midlet. Component 4 receive the SMS and forward it to component 9 and 12. Components 9 and 12 detects the message type and further verifies if the originator of the message is allowed to send the particular message type. If the access control rule doesn't allow the type of messages to be received from the originator then the message is discarded and flushed out of memory. If the originator of the message is allowed to send the particular message type then the next process begins. If the application is not active then the user is asked to enter the master pin. The Admin Key is generated using the input pin and the security data is decrypted. The security data integrity is verified as described in figure 2A. If the security data verification is successful, the application 128 Bit AES Key is generated as mentioned in the process flow in figure 3. Now the component 13 uses the application key to securely store the incoming message in the application persistent storage. The message is now available for the user to process. The user selects the message and process to read the message using the component 14 which provides the user an easy navigation for message reading and processing.

0034 If the message is of type "confidential and acknowledgement request", then the user is prompted to enter the pin for decrypting the message. The private key number or the private key to be used to decrypt the message is already known to the EMW midlet from the header of the incoming message from EMW server component 26. The key file data pertaining to the record number is decrypted

EMW MIDIet. Using the user provided PIN, the key to decipher the security data containing the key data is decrypted. The integrity of the security object is verified using the method described in figure 2A. If the verification is passed than the private key is extracted and the binary message encrypted part is decrypted and the textual part is displayed in the device screen by component 14. The user now gets the option to sign the acknowledgement data which is part of the decrypted message. The acknowledgement data is already hashed (SHA1) by the EMW server component 26 while constructing the message. The verification and extraction of private key is similar as was performed for decrypting the encrypted message in the previous user screen. Component 9A now propend the digest info bytes to SHA1 hash retrieved from the decrypted message and encrypts the concatenation of digest info bytes and message digest with the private key which results in the generation of digital signature byte^ TheJ^gojn^ to carry the digital s gnature data is formattedand sent to the component 5 for dispatching to the ~hort-from-where^~-the-messag^^ Component 5 now sends the message with digital signature to the EMW server. Once the message is sent the component 13 changes the first nibble of the first byte of the stored message in the persistent storage so that the message is marked processed.

0035 If the message is of type "sign request", component 9A extracts the hash data from the incoming message and the textual data is sent to the component 14 for displaying in the screen. The user now sees the text data which is a reference to the data or transaction the user is requested to sign. The user can now proceed to sign the transaction. The user is now asked to select the certificate which will be used to sign the transaction, if only one certificate is installed, than the choice to select the certificate is not provided but the certificate details are displayed in the screen. The validation of provided pin and extraction of private key data from the security object is same as mentioned for the message type "confidential and acknowledgement request". The user gets the option to enter the pin associated with the private key for the certificate. After the pin is validated and private key is extracted, component 14 sends the pin data, data to be signed (hash data) and key number to component 9A for processing. Component 9A now prepends the digest info bytes to the hash data and encrypts the concatenation of digest info bytes and hash data with the private key to generate the digital signature. The outgoing message which is intended to carry the digital signature data is formatted and sent to the component 5 for dispatching to the host from where the message originated. Component 5 now makes an attempt to send the message with digital signature to the EMW server. Once the message is sent the component 13 changes the first nibble of the first byte of the stored message in the persistent storage so that the message is marked processed.

0036 The EMW server receives the signed message from the EMW midlet mobile

through component 18. The message ID is extracted from the incoming message. Component 17 extracts the transaction data related to the message ID from component 25 and starts the process of PKI validation which includes the signature verification. The key number is extracted from the message data and corresponding certificate is extracted from component 24 using which the signature validation will be performed. Component 22 is used to check for any CRL entry corresponding to the certificate serial number in question. If the CRL validation is successful, component 17 uses component 21 to find the certificate status using the OCSP protocol from the corresponding certifying authority. If the processes of CRL and OCSP validation are passed, component 17 deciphers the signature using the public key associated with the extracted certificate. The decrypted data is digest info appended with the hash. The hash is extracted and compared with the pre calculated hash in the component 25 transaction database. If the hash value matches then the signature verification is termed successful by the EMW server. The EMW server now updates the record in the transaction database against the acknowledgement number assigned to the service provider with the status of signature verification and with the signed XML data.

0037 The Service Provider application initiates a call with the EMW web service with the acknowledgement number. The EMW Server component 20 web service responds with the status of the transaction with the signed XML data.

0038 Messaging Life Cvcle Description (Peer to Peer Confidential Messaging): The peer to "peer confidential messaging wherein the exchange of confidential message is established between two devices having the EMW MIDIet. The access control logic is not enabled in this process. The EMW MIDIet allows the user to decrypt message originating from any source. For sending confidential message to another device it is important that the MIDIet device have the public key associated with the device holding the MIDIet application. The exchange of public key is provided using component 14 using a menu driven interface using which the user can select the public key and destination number for sending the public key.

0039 User A selects the option to send his/her public key to destination host B.

Component 14 provides the option to select the public key and allows the user A to select the destination number using the user A phonebook. A special header message is generated and public key is sent to user B.

0040 If user B wants to receive confidential message from A the step as described above are repeated by B and a message is sent to A.

Claims

CLAIMS: I/We Claim

1. A method for dual layer encryption of RSA keys in a personal trusted device for secure data communication comprising of steps: creating a first authorization

PIN at the time of application installation; creating a second authorization PIN before generating RSA keys; generating RSA keys using high randomness random number; encrypting said RSA keys with a first AES key to provide a first layer of protection; re- encrypting said RSA keys with a second AES key to provide second layer of protection; wherein said first AES key is 128 bit AES key derived using a second authorization PIN and salt before generating the RSA Keys; and wherein said second AES key is a 128 bit master application AES key is derived using first authorization pin, personal trusted device's unique number and application parameters.

2. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein personal trusted device can be mobile phone, Personal Digital Assistant, multimedia mobile phone, laptop, palmtop or any device enabled with SMS capabilities.

3. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein a first authorization PIN is created by user at the time of application installation.

4. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein a second authorization PIN is user created at the time of RSA Key Generation

5. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein a second authorization PIN derives a certificate access key to access the private key for accessing confidential messages and for digital signing.

6. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein said high randomness random number is generated by mixing server random and secure random.

7. A method for dual layer encryption of RSA keys as claimed in claim 1, wherein PTD's unique identity number can be IMEI or IMSI for a mobile device.

8. A two factor authorization method for secure transmission of messages between sender and recipient through an authenticating server consists of receiving a binary message from an authenticating server on a personal trusted device (PTD);

prompting the recipient to input first authorization PIN; generating a first runtime AES key through first authorization PIN provided by user; validating the first authorization PIN by making an attempt to decrypt the security data which is followed by verifying the structure of the decrypted security data. The verification process involved in verifying the structure of security data involves extracting the hash SHA1 data from the decrypted data and generating hash SHA1 of the remaining data. If the extracted hash and generated hash matches, access is granted to the user and application AES key is extracted from the decrypted security data block. The application AES key is now mixed with I MSI/I M El/ PTD's unique identity number to generate the said run time second AES key using which the entire persistent storage is encrypted or decrypted; displaying the message or prompting recipient to input a second authorization PIN and using the said second AES key to unlock the RSA keys for extracting private key for displaying confidential messages and digital signing.

9. A two factor authorization method as claimed in claim 8, wherein said binary message is generated from the message sent by the said sender for the said recipient at said authenticating server.

10. A two factor authorization method as claimed in claim 8, wherein personal trusted device can be mobile phone, Personal Digital Assistant, multimedia mobile phone, laptop, palmtop or any device enabled with SMS capabilities.

11. A two factor authorization method as claimed in claim 8, wherein the said authenticating server attaches sender's address, recipient's address, recipient's public key and message type with the said binary message before sending the said message to the said recipient .

12. A two factor authorization method as claimed in claim 8, wherein a first authorization PIN is created by user at the time of application installation.

13. A two factor authorization method as claimed in claim 8, wherein a first runtime AES key is a 128 Bit Key and, is generated using salt and the said first authorization PIN as an input.

14. A two factor authorization method as claimed in claim 8, wherein digest data comprises of salt and application AES key parameters.

15. A two factor authorization method as claimed in claim 8, wherein stored SHAl is comprises of salt and application AES key parameters which is encrypted using a master AES key at the time of application installation.

16. A two factor authorization method as claimed in claim 8, wherein a second AES key is 128 bit key which is generated using application AES key parameters and using said PTD's unique identity number.

17. A two factor authorization method as claimed in claim 8, wherein PTD's unique identity number can be IMEI or IMSI for a mobile device.

18. A two factor authorization method as claimed in claim 8, wherein a second authorization PIN derives a certificate access key to access the private key for accessing confidential messages and for digital signing.

19. A two factor authorization method as claimed in claim 8, wherein a second authorization PIN is user created at the time of RSA Key Generation.

20. A two factor authorization method as claimed in claim 8, wherein the said RSA keys are dual protected by second AES key and master AES key.

21. A two factor authorization method as claimed in claim 15, wherein the said master AES key is 128 bit key and is generated using salt and said first authorization PIN at the time of application installation.

22. A system for secure transmission of message from sender to recipient through a authenticating server comprising a personal trusted device installed with EMW MIDLET application and a authenticating server;

wherein authenticating server is so configured to verify the recipient data associated with the sender's binary message, encrypt the binary message and store said message for later stage validation, and associate recipient's public key;

and

wherein personal trusted device installed with EMW MIDLET application is so configured to provide high randomness random number for generation of RSA keys and a dual layer protection to RSA keys.

23. A system as claimed in claim 22, wherein the authenticating server verify recipient's data through registration database and certificate database maintained at the said server.

24. A system as claimed in claim 22, wherein the authenticating server stores said binary message at PKI engine and validation service unit.

25. A system as described in claim 22, wherein high randomness random number is generated by Secure Random Mixer Component after interaction with server random and secure random generated by said PKI engine and validation service unit.

26. A system as described in claim 25, wherein the said high randomness random number is used by cryptographic service provider API for generation of RSA key pair.