HK1078708B - Method for authenticating and verifying sms communications - Google Patents

Abstract

A method for operating a first computational device to facilitate the secure transfer of a message between the first computational device and a second computational device is described. The method comprises operating the first computational device according to the following steps: forming an encrypted message from the message on the basis of a key derived from one or more codes associated with the second computational device; transmitting the encrypted message to the second computational device; purging the message and the encrypted message from the first computational device; receiving the encrypted message and said one or more codes from the second computational device; upon decrypting the message on the basis of the one or more codes transmitting the decrypted message to the second computational device.

Description

Method for authenticating and verifying SMS communication

Technical Field

The present invention relates to a method for facilitating secure transactions over a wireless medium. More particularly, the present invention relates to a method of authenticating text messages sent to a wireless device, such as a personal telephone.

Background

The use and penetration of computing devices such as mobile or cellular telephones and related technologies such as PDAs (personal digital assistants) has increased significantly over the past decade. In addition to providing voice communication, modern personal phones support SMS (short message service), in which text messages of up to 160 characters can be entered using the sender's telephone keypad or using a PC keypad and via the internet, transmitted over the telephone network, and displayed on the screen of the recipient's telephone.

Various services related to SMS have now been developed. One such service may be the transmission of text messages from a content sender, such as a personal computer networked to the internet, to an SMS web server by means of the associated called personal telephone number. The SMS web server provides a gateway to the telephone network to transmit messages to the called personal telephone and to have the messages displayed thereon in a standard SMS format.

Although there has been no report of successful interception of SMS messages under GSM specifications via the SMS protocol, SMS applications for the transmission of confidential information such as financial transaction data are limited due to the perceived insecurity of SMS transmission. Secure cell phone banking solutions have been proposed that use a SIM component to solve the template and security problems by improving the SIM card of the individual phone user. However, authorization and permission must be obtained from the SIM card provider of each carrier. To be able to utilize SMS banking services of a particular financial institution, a user must purchase a SIM card from a provider authorized by the financial institution.

Disclosure of Invention

According to a first aspect of the present invention, there is provided a method of operating a first computing device to facilitate secure transmission of a message between the first computing device and a second computing device, the method operating the first computing device by:

forming an encrypted message from the message based on a key generated from one or more codewords associated with the second computing device;

sending the encrypted message to a second computing device;

clearing the message and the encrypted message from the first computing device;

receiving an encrypted message and the one or more codewords from a second computing device;

after decrypting the message based on the one or more codewords, the decrypted message is sent to the second computing device.

In a preferred embodiment, the first computing device includes a computer network server in communication with a cellular telephone network. The computer network may be the internet. The message may be generated by the content sender in the form of a personal computer connected to the first computing device over a network such as the internet.

Additionally, the first computing device may include a cellular telephone.

Assuming that the second computing device is typically a cellular telephone, the message is sent to the cellular telephone in an SMS format.

The step of forming an encrypted message typically includes forming a key based on the phone number of the cellular telephone and a personal identification number used by the owner of the cellular telephone.

In a preferred embodiment, the step of sending the encrypted message to the cellular telephone includes sending a message identifier associated with the encrypted message.

Preferably, the cellular telephone sends the encrypted message back to the first computing device along with the message identifier.

The method may further comprise the steps of: if the message identifier is not received from the cellular telephone within a predetermined time period, the first computing device generates an error code.

In a preferred embodiment, the one or more code words include a Personal Identification Number (PIN) and a telephone number (CLI) associated with the cellular telephone.

The first computing device may check whether the Personal Identification Number (PIN) and the telephone number (CLI) are consistent in length and/or field type.

Preferably, the method further comprises the step of sending an error status message to the content sender that indicates any error condition.

The method for facilitating secure transmission of a message between a first computing device and a second computing device if mutual authentication between the first computing device and the second computing device is required operates by:

encrypting the message using the public key of the second computing device;

attaching a digital signature to the encrypted message, the digital signature being generated based on a personal key of the first computing device;

sending the encrypted message and the digital signature to the second computing device;

the second computing device receives the encrypted message and the digital signature and decrypts the digital signature based on the public key of the first computing device; and

the encrypted message is decrypted using the personal key of the second computing device.

The method may be used to conduct financial transactions between a financial institution and a customer of the institution, wherein the customer operates a cellular telephone and the institution operates a computer network server.

Another aspect of the invention provides a computer software product provided by a computer readable medium for execution by a computing device, the computer readable medium comprising instructions for:

forming an encrypted message from the message based on the key;

sending the encrypted message to a second computing device;

clearing messages and encrypting messages;

receiving an encrypted message and the one or more codewords from a second computing device;

after decrypting the message based on the one or more codewords, the decrypted message is sent to a second computing device.

Other features of the present invention will become more apparent with reference to the following detailed description and accompanying drawings.

Drawings

FIG. 1 is a block diagram of a preferred embodiment of a method for implementing secure messaging.

Fig. 2 includes the entities of fig. 1 and also represents messages transmitted between the graphical representations in a secure messaging method.

Fig. 3 is a flowchart of a method for operating a security server to process a message sent to a receiver according to a preferred embodiment of the present invention.

Fig. 4 is a flowchart of a method of operating a security server for processing a message from a receiver in a preferred embodiment of the present invention.

Figure 5 illustrates the application of the secure messaging method in one embodiment of the present invention.

Figure 6 illustrates the steps of a funds transfer operation in one embodiment of the present invention.

Fig. 7 illustrates the steps of a B-Pay payment operation in one embodiment of the invention.

FIG. 8 illustrates the steps of a funds balance query operation in one embodiment of the invention.

FIG. 9 illustrates parties to a transaction in another embodiment of the invention.

FIG. 10 illustrates transaction steps in another embodiment of the invention.

Detailed Description

Fig. 1 illustrates the contents of a secure SMS transaction in a preferred embodiment of the invention. The content sender 2 is typically a user workstation, such as a personal computer, which generates messages that are sent to the receiver 6. The security server 4 is a web server that communicates with the content sender. The secure server executes a software product including instructions that implement an embodiment of the invention. The security server is able to establish a communication with the receiver 6, which is typically an SMS personal phone. The communication between the content sender 2 and the security server 4 may be via an SSL (secure socket layer) internet connection, for example, the security server 4 provides a gateway between the content sender and a personal telephone network accessed by the receiver 6. The functions of the security server 4 may be integrated into the content sender 2. Further, content sender 2 may comprise a personal telephone. Thus, another embodiment of the present invention may facilitate secure messaging directly between two computing devices, including personal phones.

A secure communication method according to a preferred embodiment of the present invention will be described with reference to fig. 2, 3, and 4. First, in block 18 of fig. 3, the security server 4 waits for an incoming data packet 8 from the content sender 2. The data packet 8 comprises a message to the receiver 6, and the receiver's PIN number and phone number or line identifier (CLI). By prearrangement, both the content sender 2 and the receiver 6 can learn the PIN number when the holder of the receiver 6 accesses the secure transaction service. At the time of access, the phone number of the receiver 6 is also provided to the content sender 2.

In block 20 (fig. 3), the secure server 4 assigns a unique Message Identifier (MID) to the received packet. In block 22, the message identifier is stored in the memory of the security server 4. In block 24, the telephone number (CLI) and PIN of the receiver are retrieved from the data packet 8.

In block 26, the secure server generates an encryption key from the PIN and CLI according to a standard algorithm. If mutual authentication is required, a PKI (public key infrastructure) technique may be employed in which a message is encrypted using a sender's personal key and a receiver's public key.

A variety of cryptographic techniques are known and described in the following documents: applied cryptography, Second Edition: protocols, algorithms, and source code in C, ISBN 0-471-.

In block 28, the message is encrypted using the encryption key, thereby producing an encrypted message Enc { Msg }. In block 30, the encrypted message and the unique message identifier MID are formed into a packet, forming a data packet 10. The data packet 10 also includes a text message which is displayed at the receiver 6 as a request to enter the user's PIN. In block 32, the data packet 10 is transmitted to the receiver 6. In block 34, the security server removes its own information from the data packet 8, including the message, PIN number, phone number, key, and encrypted data. A clock is simultaneously started to record the transmission time of the message assigned in block 22 with the unique message identifier. The MID is registered in the server 4 together with the termination value for later use, as will be described later.

It is noted that since there is no copy of the message, and hence either the plaintext or the encrypted text is stored in the secure server 4, the likelihood of a hacker successfully intercepting the message from the secure server after it has been sent to the receiver 6 is greatly reduced. Most financial institutions require that sensitive information not be stored in the server. The message is encrypted and sent to the receiver so that only the receiver, knowing the PIN and having the correct personal telephone SIM, can retrieve a clear message. Even if a person without a PIN picks up the receiver's personal phone, he/she can only see a scrambled encrypted message. The receiver needs to send back an encrypted message with his/her PIN from his/her SIM to enable successful decryption of the message.

After the receiver 6 receives the data packet 10, it displays a text message that the PIN needs to be entered. The user of the receiver 6 answers by entering the PIN. The data packet 12 is sent back to the security server 4. Packet 12 includes the receiver's phone number (CLI), the PIN, the packet 10's Message Identifier (MID) information, and an encrypted message Enc { Msg }.

In block 38 (fig. 4), the secure server 4 receives the data packet 12 from the receiver 6.

The security server obtains the message identifiers MID and CLI from the data packet and checks whether the end value of the message identifier exceeds the block 40. If the timer has expired, control passes to block 41 where an error message is sent to the content server. In blocks 42 and 46, the message ID and the user telephone number are extracted from the incoming data packet.

In block 44, it is checked whether the message ID is legitimate. In block 48, the user's PIN is extracted from the incoming data packet. A check is made in block 50 to ensure that the PIN and the receiver telephone number (CLI) are correct. In block 52, a key is generated from the phone number and PIN of the receiver. In block 54, the encrypted message Enc { Msg } is decrypted using the key. In block 60, the receiver's phone number is used to send 14 of fig. 2, i.e., the decrypted message, to the receiver 6. In block 62, the status message is sent to the content sender 2 along with the Message Identifier (MID)16 (FIG. 2). The status message includes an error code that reflects whether the authentication and verification process was successfully completed.

The error code may indicate whether the message identifier received from the receiver 6 is illegal, whether the PIN and/or CLI from the receiver is illegal, or whether the Enc Msg decryption from the receiver was unsuccessful. If no error occurs, an error message will indicate that the process was successful.

In block 64, the security server clears the user PIN, receiver phone number, encryption key, and decryption message from its memory.

The software product executable by the security server 4 for implementing the above method preferably comprises the following instructions:

forming an encrypted message from the message of sender 2 based on the secret key;

sending the encrypted message to a second computing device, such as receiver 6;

clearing messages and encrypting messages;

receiving an encrypted message and one or more codewords from a second computing device;

after decrypting the message based on the one or more codewords, the decrypted message is sent to a second computing device.

An example of an application of the authentication and verification method shown in fig. 1-4 is described below with reference to fig. 5, in which the same icons as in fig. 2 are used to identify similar items. The stockbroker 70 generates a message through the content sender (personal computer) 2 after ending the stock exchange of the client holding the receiver 6 (i.e., personal phone). The message is encrypted and sent to the customer's personal telephone 6. The customer enters the PIN into the receiver 6 which is sent back to the security server 4 together with the encrypted message and the customer's telephone number (CLI). This is typically done using a "reply" function on the personal telephone. The security server receives the response from the receiver 6 and decrypts the message using the CLI and PIN to generate a decryption key.

The decrypted message is sent back to the receiver and a status message is sent back to the content sender 2 to confirm that the message was successfully transmitted and to provide an error code if the transmission failed.

Fig. 6 is a flow chart of a transaction between a personal telephone subscriber 6 and a network server 4 of a financial institution. First, in block 72, the personal telephone user may initiate a funds transfer by sending an SMS message to the secure web server 4 using the user name.

The network server verifies the user who is using the CLI of the personal phone and the user name in the message. The web server 4 responds to the SMS menu with the option number. The option may be, for example, a balance of funds inquiry, a money transfer, or a payment. In block 76, the user receives the menu message and responds by selecting the desired option. For example, user 6 may decide to exchange funds.

In block 78 the secure network server 4 checks the user that is using the CLI and sends a corresponding response depending on which menu the user selected in block 76. For example, the secure web server may send a request to the user 6 to confirm which account to transfer funds on. In block 80, the user enters any data required for the exchange, thereby accessing the personal telephone 6. The data may be the amount of money to be transferred, the account identification number to be transferred, and the account number of the other party. In block 82, the secure web server 4 verifies the user again based on the CLI of the personal phone. An encrypted SMS message is sent to confirm that the funds transfer is ready. In addition, an unencrypted message is sent requesting the user to enter the PIN. In block 84, the user receives a request for a PIN, sends a PIN and encrypted message back. In block 86, the server verifies the user who is using the CLI of the personal phone, the PIN and the encrypted message receipt. After verification, confirmation of the requested transaction is sent back to the user 6 and displayed on the user's personal telephone in block 87. For example, such a message may be sent: "you have remitted < amount > from < account No.1> to < account No.2 >.

Fig. 7 is a flow chart of the exchange of information between a personal telephone subscriber 6 and the financial institution's web server 4 to conduct a B-Pay transaction. First, in block 88, the personal telephone user may send an appropriate SMS message to the secure web server 4 using the user name to initiate a B-Pay transaction. In block 90, the network server verifies the user who is using the CLI of the personal phone and the username in the message. The web server 4 responds to the SMS menu with the option number and including the B-Pay transaction option. For example, the B-Pay transaction options may be a funds balance option and a funds transfer option. In block 92, the user receives the menu message and responds by selecting the B-Pay transaction option. In block 94 the secure network server 4 verifies the user who is using the CLI and sends a corresponding response, such as asking which account the B-Pay transaction came from.

In block 96, the user enters the transaction debit account number and the code of the B-Pay payee. In block 98, the secure web server 4 verifies the user again based on the CLI of the personal phone. An encrypted SMS message is sent to the user's personal telephone to confirm that the funds transfer is ready and to request the user to enter a PIN after confirmation of the transaction request. In block 100, the user receives a request for a PIN, enters the PIN number into personal telephone 6, and transmits it to network server 4. A message including the PIN number and the encrypted message are returned to the network server 4.

In block 102, the server verifies the user, the PIN and the encrypted message receipt using the CLI of the personal phone. After verification, confirmation is sent back to the personal telephone that the requested transaction has ended. In block 103, a confirmation message is displayed on the personal telephone.

Fig. 8 is a flowchart of the balanced inquiry by exchanging information between the personal telephone user 6 and the secure network server 4 of the financial institution. First, in block 110, the personal telephone user may initiate a balanced query by sending an appropriate SMS message to the secure web server 4 using the user name. In block 112, the network server verifies the user who is using the CLI of the personal phone and the username in the message. The web server 4 responds to the SMS menu with an option number, including a balanced query option. Other options on the menu may be, for example, a money transfer option and a B-Pay payment option.

In block 114, the user receives the menu message and selects the balance inquiry option in response. In block 116 the secure network server 4 checks for a user who is using CLI and sends a corresponding response, such as a query to balance the account number from which the query came. In block 118, the user selects the account number to be queried. In block 120, the secure web server 4 verifies the user again based on the CLI of the personal phone. An encrypted SMS message confirming that the queried balance list is ready is sent to the user and requests the user to enter his/her PIN. In block 122, the user receives the encrypted message and a PIN request. The user enters a PIN number into the personal telephone 6 and sends the PIN and encrypted message back to the network server. In block 124, the server verifies the user who is using the CLI of the personal phone, the PIN, and the returned encrypted message. After verification, an unencrypted message is sent back to the user's personal telephone 6 regarding the funds balance for the account and displayed on the personal telephone in block 125.

Another embodiment of the present invention will be described below with reference to fig. 9. In fig. 9, X-party 152 issues an instruction to his bank server, host X154, to transfer funds to a Y-account, where host Y is a server of the Y-party's bank.

FIG. 10 shows the following steps in an example method:

the host Y in the X direction sends a message for exchanging to the Y direction. For example, the message may be "remit $100 to the Y party account through a bank. "in this case, party X wishes to exchange funds with party Y account through a bank.

2. Host X next requests the public key of party Y from a local or external library 156, (which may be a database within host Y) and then encrypts the message from party X.

3. Host X then generates a unique random Message ID (MID), encrypts the ID with the X party's public key, and sends back to X party.

Party X responds with his PIN. If he still has his SIM, this will verify that the PIN of party X is not exposed.

5. The host X decrypts the X party's personal key (asynchronous to the key) using the provided PIN and decrypts the MID using the personal key. If the MID does not match the MID stored in host X, the transaction is recorded as fraudulent activity.

6. The host X encrypts the one-way hash value of the encrypted message generated in step 2, again using the X party's personal key (still temporarily decrypted). It corresponds to a digital signature-as long as party X is the generator of the message. The signature is appended to the encrypted message in step 2.

7. The encrypted message and digital signature are sent to host Y via a secure channel 164. For example, the message may be sent in HTTPS format, or may be sent over the internet over a dedicated (wired) line to a private communication network or virtual private network.

8. After host Y receives the encrypted message from host X, it requests the public key of party X from the public key database 156 and decrypts the digital signature. The encrypted message is then hashed and the two hash values are compared. This comparison is used to verify the generator of the message (X-party) to ensure that the message has not been attacked.

9. The encrypted portion of the message (i.e., the message from party X that has been encrypted by the public key of party Y) is sent to party Y along with the original source of message X.

The Y party then returns the message and his private PIN.

11. The personal key of the Y party is decrypted by the PIN provided and the message is decrypted.

12. If the message is successfully decrypted, it is returned to party Y and a notification is sent back to host X informing party X of the fact that the decryption has been successful.

It should be noted that the transaction method described above has many advantages from the point of view of the Y party.

Confidentiality-since the message is encrypted with the public key of the Y-party, only the Y-party can decrypt the message with his personal key.

Authentication-the message is successfully decrypted using the public key of party X, which means that only using the personal key of party X, the encryption can be done first.

Data integrity-the point that the Y party is not attacked for the message from the X party can be relieved.

Non-repudiation-party X cannot later repudiate the unsent message, nor the message content, for the following reasons: first, any entity can encrypt a message for transmission to party Y by party Y's public key, but the entity cannot access party X's personal key and use it to encrypt the hash value.

Second, the hash value is unique to a particular message, i.e., different content may produce a hash output different from the content received and successfully decrypted.

From the perspective of the X party, the trading method has many of the following advantages:

confidentiality-for messages encrypted with the public key of the Y-party, only the personal key of the Y-party can be used for decryption.

Authentication-the encrypted message can only be decrypted with the personal key of the Y party.

Data integrity an X party can be relieved of the point that messages to a Y party are not attacked.

Non-repudiation-party Y cannot later repudiate the received message for the following reasons: first, only Y-party can decrypt the master message with the Y-party's personal key for mediation before generating the hash value using a hashing method. Second, the hash value is unique to a particular message, i.e., different content causes a mediation failure.

In the case of fig. 9 and 10, the individual key is stored in the server in an encrypted form, i.e., a synchronized form. The only way to access the keys is to decrypt them with a key provided by the end user. Obviously, this method allows users to set their own personal keys as the master in their phones or other devices.

The method in embodiments of the invention may be used for other financial transactions between a remote personal telephone user and a server of a financial institution. The system may also be used to make credit card payments, for example. In addition, the encrypted message may be sent through a Multimedia Messaging Service (MMS) picture. For example, steganography may be used to embed the message into the picture. In this way, a person's picture can be used to verify an entity, while the content built into the picture can be used to send information. That is, the message generator can be visually and electronically identified.

Although the present invention has been described in connection with the preferred embodiments, it is not intended that the present invention be limited to these embodiments. Those skilled in the art will recognize that the same methods, structures, arrangements, procedures, steps and other variations may be practiced without departing from the scope of the following claims.

Claims (13)

1. A method of operating a first computing device to facilitate secure transfer of a message between the first computing device and a second computing device, the method operating the first computing device by:

forming an encrypted message from the message based on a key generated based on one or more codewords associated with the second computing device;

sending the encrypted message to a second computing device;

clearing the message and the encrypted message from the first computing device;

receiving an encrypted message and the one or more codewords from a second computing device;

and after the message is decrypted based on the one or more code words, the decrypted message is sent to the second computing device.

2. The method of claim 1, wherein the first computing device comprises a computer network server in communication with a cellular telephone network.

3. The method of claim 2, wherein the computer network is the internet.

4. The method of claim 1, wherein the message is generated by the content sender in the form of a personal computer connected to the first computing device via a network.

5. The method of claim 1, wherein the first computing device comprises a cellular telephone or a wireless personal digital assistant.

6. The method of claim 1, wherein the second computing device comprises a cellular telephone.

7. The method of claim 6, wherein the step of forming an encrypted message comprises forming a key based on a phone number of the cellular telephone and a personal identification number used by an owner of the cellular telephone.

8. The method of claim 7, wherein the step of sending the encrypted message to the cellular telephone comprises sending a message identifier associated with the encrypted message.

9. The method of claim 8, wherein the cellular telephone sends the encrypted message back to the first computing device along with the message identifier.

10. The method of claim 8, further comprising the steps of: if the message identifier is not received from the cellular telephone within a predetermined time period, the first computing device generates an error code.

11. The method of claim 7 wherein the one or more codewords comprise a personal identification number and phone number associated with the cellular phone.

12. The method of claim 11, wherein the first computing device checks whether the personal identification number and the phone number are consistent in length and/or field type.

13. The method of claim 1, further comprising the step of sending an error status message to the content sender for alerting the content sender of any error conditions.