A transaction system combats malware and phishing-based MitM attacks on transaction processing systems by using digital signatures to integrity-protect the user-verified transaction data. With this system, a user submits a transaction from a client device (e.g., desktop web browser) over a communications channel to a server device, such as a transaction server. Before accepting the transaction, the transaction server securely delivers all relevant transaction data to a second device (e.g., the signing device), such as a smart phone, in the possession of the user. The signing device has its own distinct communication channel with the server device. The user verifies the data and the signing device creates a digital signature value for the transaction. The user submits the signature to the transaction server to confirm the transaction with the transaction server.

BACKGROUND

Client-server systems provide electronic access by the client to data, information, accounts and other material stored at the server. In financial transactions, the system provides a client electronic access to accounts and financial resources. In a client-server transaction, a client device is required to prove to the server device that it is an authentic client, and not some impersonator or other unauthorized party. Protocols are known by which a client device proves to a server device its authenticity, while at the same time it does not reveal information that could be misused by a third party. In one arrangement, certain client-server systems utilize transaction signing to allow client devices the ability to prove authenticity to a server device.

For example, certain transaction signing solutions use a single device platform (e.g., the client device, such as a user's personal computer) to both submit a transaction request to a transaction server and to generate a transaction signature. Other, more secure transaction signing solutions utilize a second, signing device for generation of the digital signature. In use, the client device transmits a transaction request to the server device over a network connection. In response, the server device transmits certain transaction information back to the client device via the network connection. Upon receipt of the transaction information by the client device, the client device operator enters required parts of the transaction information into the signing device, where the signing device is disconnected from (i.e., not disposed in electrical communication with) both the client device and the server device. Once the signing device generates and displays a resulting electronic signature, the client device operator enters the electronic signature into the client device and transmits the electronic signature to the server device to complete the transaction signing process.

SUMMARY

Conventional transaction signing solutions suffer from a variety of deficiencies. For example, the single device platform that submits the transaction request to a transaction server and generates the transaction signature is subject to malware-based and phishing-based man-in-the-middle (MitM) attacks which can surreptitiously modify the transaction data. Additionally, the use of a second, disconnected signing device to generate a digital signature, while providing a more secure transaction signing solution, requires the client device operator to manually enter important transaction data into the client device. Such a process can be error-prone and limit the amount of data that can be realistically included in the signature. In addition, such signing devices are often relatively expensive to manufacture and purchase.

By contrast, embodiments of the present invention relate to a transaction system that combats malware and phishing-based MitM attacks on transaction processing systems by using digital signatures to integrity-protect the user-verified transaction data. With this system, a user submits a transaction from a client device (e.g., desktop web browser) over a communications channel to a server device, such as a transaction server. Before accepting the transaction, the transaction server securely delivers all relevant transaction data to a second device (e.g., the signing device), such as a smart phone, in the possession of the user. The signing device has its own distinct communication channel with the server device. The user verifies the data and the signing device creates a cryptographic digital signature value for the transaction. The user submits the signature either via the client device or directly from the signing device to confirm the transaction with the transaction server.

By generating the transaction signature on a signing device separate from the client device where the transaction was initiated, the transaction system provides a level of security to the transaction between the client device and the transaction server. The transaction system takes advantage of connectivity available in today's mobile devices (e.g., smart phones) to securely deliver the transaction data to the signing device, (e.g., a signing application executed by the signing device). This minimizes or eliminates usability problems typically associated with manual data entry of the transaction information into the signing device.

Additionally, the proposed solution can be implemented in a software-based form-factor using a mobile phone as the signing device, which has significant cost and deployment advantages over hardware-based signing devices. Another advantage is the ability to provide privacy protection and authentication by encrypting and signing the transaction data being sent to the signing device.

DETAILED DESCRIPTION

FIG. 1illustrates a schematic representation of a transaction system10having a client device20, a signing device30, and a transaction server40. The signing device30, such as a smartphone (e.g., a mobile telephone configured with computer-like capabilities), and the transaction server40communicate with each other via a first communication channel24. While the first communication channel24can be configured in a variety of ways, in one arrangement, the first communication channel24is configured as a network connection, such as an Internet connection, provided by the mobile operator of the signing device30. In another arrangement, the first communication channel24is configured as a cellular telephone network connection. The client device20, such as a computerized device, and the transaction server40communicate with each other via a second communication channel22, such as a network (e.g., Internet) connection, which is distinct from the first communication channel24. It should be understood that communication channels22,24may be real-time communication channels or they may be store-and-forward type communication channels (such as for example, a channel devoted to e-mail communication) or any other kind of communication channel or a combination thereof.

The embodiments of this invention rely on one or more cryptographic keys known to the signing device30, and the transaction server40. The keys are required to perform a multitude of different cryptographic operations and will hereafter be identified by their usage during communication between the transaction server40and the signing device30. A transaction-signing key (or keys)58is used to provide integrity protection of data by creating and verifying digital signatures for the data. A transaction-encryption key (or keys)62is used to provide privacy protection of data by encrypting and decrypting the data. An authentication key (or keys)56is used to authenticate the signing device30to the transaction server40or to authenticate the transaction server40to the signing device30. As an alternative, the authentication key or keys56may be used to authenticate the signature request60. In various arrangements, the transaction signing key58, the transaction encryption key62, and the authentication key56may be identical keys, may be derived from a common master key, or may be independently provisioned keys. Finally, any of the cryptographic keys56,58,62used in this invention may be shared symmetric keys or asymmetric key-pairs.

In one arrangement, a user is in possession of the client device20and the signing device30. The client device20is configured to submit and confirm a transaction request50transmitted to the transaction server40. The signing device30is configured to generate a digital signature associated with the transaction. In one arrangement the signing device30has been provisioned with a transaction signing application and the required cryptographic keys56,58,62.

In use, the user submits a transaction request50, including transaction data52, to the transaction server40using the client device20(e.g., using a web browser executed by the client device20) over the second communication channel22. For example, the user may submit a request to transfer $5,000 from account A to account B. In response to receiving the transaction request50, the transaction server40communicates certain transaction data64as part of a signature request60to the signing device30(e.g., a transaction signing application executed by the signing device30) over the first communication channel24. The transaction server40uses cryptographic keys56,58,62to sign and encrypt the transaction data64of the signature request60for integrity and privacy protection. The transaction data64, in addition to including some or all of the original transaction data52, may also include additional data added by the remote transaction server40, such as, for example, a nonce or a challenge value to uniquely identify the transaction.

The signing device30, executing a transaction signing application, decrypts the transaction data64and verifies the signature on the transaction data64and displays the decrypted transaction data64to the user, such as by a display65associated with the signing device30. The user verifies that the transaction data64matches the original transaction data52submitted by the client device20. If the user detects a match between the transaction data52and the displayed transaction data64, the user instructs the signing device30to generate and display a digital transaction signature70for that transaction. The signing device30uses the transaction signing key58and the transaction data64transferred to the device30to generate a digital signature (e.g., a digital signature value)70for the transaction. The transaction server40prompts the user, via the client device20for the transaction signature70generated by the signing device30. The user enters the transaction signature70provided by the signing device30into the client device20and submits the transaction signature70to the transaction server40to confirm the transaction. However, in another embodiment, the signing device30sends the transaction signature70directly back to the transaction server40once the user verifies the transaction.

With such a process, by generating the transaction signature70on a signing device30separate from the client device20where the transaction was initiated, the transaction system10provides a level of security to the transaction between the client device20and the transaction server40. For example, assume that the client device20includes, unknown to the user, malware configured to modify data or other information transmitted to the transaction server40. Further assume the case where the malware were to modify the transaction data52transmitted to the transaction server40. In such a case, because of the malware's modification of the transaction data52and based upon the user's comparison of the transaction data52with the displayed transaction data64, the user can detect a difference between the data values52,64. Accordingly, with such detection, the user can reject the transaction with the transaction server40as he realizes that the security of the transaction has been compromised.

FIG. 2illustrates an example embodiment of the signing device30in greater detail. Signing device30includes a display device65, a user interface82, a network interface84for interfacing with first communication channel24(e.g., a cellular transmitter/receiver), a controller86, memory88, and an optional local connection interface90. Display device65may be an integrated display screen or it may be an external display screen. User interface82may be incorporated into the display device65, such as in the case of a touch-sensitive screen on a mobile device. Alternatively, user interface may include a separate keyboard or keypad (internal or external), a mouse, trackball, track pad, or other similar device (also internal or external), or any other input device known to Man, such as an audio input coupled with voice recognition software.

Controller86may be any sort of controller, such as, for example, a general purpose processor or microprocessor, a central processing unit, or a set of dedicated circuitry designed to perform particular operations in hardware. Memory88may be made up of one or more of the following: volatile random access memory, non-volatile read-only memory, non-volatile flash memory, magnetic storage, optical storage, etc. In one embodiment, memory88stores a transaction signing application92. Transaction signing application92contains a set of instructions to be executed by processor86in order to carry out one or more embodiments. Memory88also stores the values of the authentication key56, transaction-signing key58, and transaction-encryption key62.

In operation, signing device30performs a method100depicted inFIG. 3. It should be understood that whenever signing device30is described as performing an action, it is the controller86that performs the operation or causes the operation to be performed (in some embodiments, by performing a step stored in transaction signing application92).

The method has five steps, steps110,120,130,140, and150. Additional steps may be performed in some embodiments.

In step110, signing device30securely receives transaction data64over first communication channel24(via network interface84) from a remote server40(also known as a transaction server40or remote transaction server40), in response to a user submitting a transaction request50to the remote transaction server40via a client-side device20over a second communication channel22. Signing device30securely obtains the transaction data64within signature request60.

In some embodiments, signing device30receives the transaction data64as a signed and encrypted communication and decrypts it using encryption key62. In one embodiment, the encryption key62is identical to the signing key58, while in another embodiment, the encryption key62is distinct from the signing key58.

In some embodiments, signing device30is a cellular telephone and receives signature request60including transaction data64encoded in one or more Short Message Service (SMS) text messages (or any other cellular protocol for transmitting and receiving short messages). In other embodiments, since transaction data64may be too long to fit within a text message, signing device30is preconfigured with the URL of an Internet site from which to retrieve transaction data64, in which case, either the user directs the signing device30to visit the pre-configured URL, or remote transaction server40sends a message to signing device30instructing the signing device30to visit the pre-configured URL. In still another embodiment, signing device30receives a message by SMS, e-mail, or another data channel containing the URL of an Internet site from which to retrieve transaction data64. Signing device30then downloads the transaction data64from the Internet site (preferably in encrypted form, as above) by following the link. In other embodiments, transaction data64or a link to an Internet site containing the transaction data64may be received by the signing device30by e-mail.

It should be understood that the transaction data64typically contains a plurality of data values. In some embodiments, these data values are values that identify a financial transaction that the user desires to perform with a bank or other financial institution via the remote transaction server40.

In step120, signing device30displays at least part of the received transaction data64in a format visible to the user. This is done by displaying the transaction data64on display65so that user can see the transaction data64. There may be more transaction data64than can be displayed on the display65at one time. In such a case, the transaction data64may be displayed in a scrollable window so that the user can scroll through the transaction data64. In some embodiments, only part of the transaction data64is displayed. In some embodiments, signing device30may pre-mark certain data values within the transaction data64. In one embodiment, any data value that has previously been received and confirmed as accurate in a previous transaction may be marked as Previously-Verified. In another embodiment, any data value that has not been previously received and confirmed as accurate in a previous transaction may be marked as Suspect. For example, Suspect data values may be displayed in a bold red color to stand out to the user.

In step130, signing device30receives confirmation from the user, via the user interface82, that the displayed transaction data64is correct. The transaction data64displayed on display65should match the transaction data52originally entered by the user while first setting up the transaction request50. Since it would be difficult for a counterfeit remote server to be aware of this data, the user can verify that the signing device30has connected with the correct remote transaction server40. In some embodiments, if any of the data values displayed within the transaction data64have been marked as Suspect (or, alternatively, have not been marked as Previously-Verified), signing device30may be configured not to actually confirm the transaction data until the user independently verifies each Suspect data value.

In some embodiments, in addition to the user confirming the correctness of the transaction data64displayed on display65, the user may also input additional transaction data not transmitted to the signing device30by the remote transaction server40. This may provide additional security, provided that only a small amount of data is so provided. For example, the transaction data64may not include the dollar amount of the transaction. Thus, in order to fully confirm the transaction, the user is asked to enter the dollar amount of the transaction (e.g., $5,000) into the signing device. This additional transaction data is also used by the signing device30to calculate the transaction signature70in step140, below.

In step140, once the transaction data64(including any Suspect values) has been verified by the user, signing device30calculates a transaction signature70based on the received transaction data64and signing key58(which may or may not be the same as or related to encryption key62). For example, signing device may use a cryptographic hashing procedure on the received transaction data64. In some embodiments, the additional transaction data entered by the user is used in this calculation as well. The cryptographic transaction signature70may be a numeric value or it may be a visual representation, such as, for example, a barcode. By cryptographically processing the transaction signature70, once remote transaction server40eventually receives the transaction signature70(as described below in connection with alternative steps150and180), remote transaction server40can verify that the user of the client-side device20is also in possession of an authorized signing device30and that the user is therefore unlikely to be a malicious attacker who has stolen the user's information and is attempting to submit a fraudulent transaction. This is because signing key58is known only to remote transaction server40and signing device30.

After step140, there are several possible conclusions to method100. These conclusions are subsumed within general step145, in which the signing device30delivers the signature to another entity for authentication. General step145has at least three possible paths—beginning with steps150,160, and170.

In step150, signing device30sends the transaction signature70directly back to remote transaction server40via first communication channel24once the user verifies the transaction data64.

In alternative step160, signing device30displays the transaction signature70to the user on display65. The user is then able to perform step165by entering the transaction signature70into the client-side device20(e.g., into a dialog box presented by a browser running on client-side device20upon attempting to complete a transaction). In one embodiment, user uses a scanning device of the client-side device20to scan a bar code representing the transaction signature70displayed on display65.

Alternatively, in step170, signing device30may communicate directly with client-side device via local connection interface90(e.g., a universal serial bus connection) and send the transaction signature70to the client-side device20over the local connection interface90.

Following steps165or170, the client-side device20sends the transaction signature70to the remote transaction server40over the second communication channel22so that the remote transaction server40can authorize the transaction.

For example, if substantially identical transaction data52is used in multiple transactions between the client device20and the transaction server40, the signature values70for those transactions may be identical. To minimize the possibility of duplicate signature values70and to configure the system10to treat each transaction between the client device20and the transaction server40as being unique, the signing device30is configured to include transaction-specific data (e.g., a nonce, transaction ID, timestamp, etc,) when generating or computing the transaction signature70.

As indicated above, the transaction system10includes two distinct communication channels; a second communication channel22between the client device20and the transaction server40and a first communication channel24between the transaction server40and the signing device30. In one arrangement, malware on the signing device30could potentially bypass the security provided by the system10by utilizing the signing device30for both submission of the transaction request50(e.g., using their mobile device browser) and the transaction signature70generation. In one arrangement, the transaction server40is configured to perform a risk-based authentication (RBA) utilizing geo-location information associated with the communication channels22,24. For example, the transaction server40can be configured to check geo-location information associated with the devices20,30, such as an Internet Protocol (IP) address associated with the client device20and the signing device30, to ensure separate communication channels22,24are being used. It should be noted that the risk-based authentication (RBA) can also be performed by the signing device30, in an alternate embodiment, as well.

As indicated above, transaction data64is verified by a user. In one arrangement, a complicated transaction can include a plurality of data values encoded using many symbols such as letters or digits. Accordingly, user verification can be error-prone. In one arrangement, to minimize errors, to provide an additional verification check, the signing device30is configured to hash at least part of transaction data values64and display the hash, a value derived from the hash value, or an image or images associated with at least parts of the hash values on the signing device30. The transaction server40can then instruct the user to only transmit the transaction signature70to the transaction server40if the hash, the value derived from at least part of the hash value, or the one or more images associated with at least part of the transaction data values64or hash value displayed by the signing device30is recognized by the user. Visual verification of generated images can be less error prone than strings representing the hash values.

In one arrangement, as indicated above, the signing device30has been provisioned with a transaction signing application92and a signing key58, such as a symmetric key, shared with the transaction server40. The symmetric signing key58, as known by the transaction server40and the signing device30, can be a seed value usable in other algorithms, such as authentication and signing algorithms. The symmetric signing key58, therefore, allows for strong two-factor authentication (2FA) to be used to gain access to the transaction services and signing of the transactions to be accomplished using the same key. While a symmetric signing key58can be used as part of the transaction system10it should be understood that a variety of other types of keys can be used as well. For example, the transaction server40and the signing device30can be configured to utilize an asymmetric key-pair.

In one arrangement, the transaction system10uses the concept of whitelisting to ensure that parts of the received transaction data64are utilized for well-known or approved use. For example, in one arrangement, transactions typically occur between specific account numbers. The signing device30may check the account numbers and if they have not been previously utilized may disallow signing of the transaction or additionally indicate to the user that the account numbers are not recognized. In another arrangement, whitelisting is applied to URLs that specify the address of an Internet site from which to retrieve transaction data64.

In another arrangement, the transaction system10incorporates the concept of whitelisting to ensure that the communication channels22,24are utilized for well-known or approved use. For example, in one arrangement, transactions typically occur during specific time periods (e.g., transactions occur over communication channels22,24between 9 AM and 5 PM Eastern Standard Time, Monday through Friday). Accordingly, with the concept of whitelisting, the communication channels22,24are associated with this particular timeframe. Accordingly, when the communication channels22,24are utilized, the transaction server40reviews the time of utilization of the channels22,24. If the time of utilization of the channels22,24falls within the aforementioned timeframe, the transaction server40allows the transaction to continue. However, if the time of utilization of the channels22,24falls outside of the aforementioned timeframe, the transaction server40disallows continuation of the transaction. While the concept of whitelisting can be applied to the communication channels22,24, whitelisting can also be applied to other aspects of the transaction system10as well.

For example, certain transaction details may be pre-configured within signing device30. Thus, signing device30may be pre-configured to only accept transfers that originate or terminate in a particular bank account. For example, a corporate treasurer may only be authorized to transfer money from or to a particular corporate account. If transaction data64received by signing device30indicates any other account, transaction data64may be modified to included the pre-configured account instead of the originally-received account before the transaction signature70is calculated, which would flag to the remote transaction server40that the transaction data64was incorrect. In another embodiment, the pre-configured details may not be transmitted within the signature request60at all. In such case, the signing device30may automatically fill in the missing details, such as the destination account number. If multiple destination accounts are permitted, the signing device30may prompt the user on screen64to ask which of the several pre-configured destination accounts the user wishes to send the money to. If the original transaction data52indicated a different account, then the transaction signature70would indicate to the remote transaction server40that the user may be attempting an unauthorized transfer.

As indicated above, the transaction server40transmits the signing request60to the signing device30using the first communication channel24. It should be noted that the signing request60can be transmitted in a variety of ways. For example, the signing request60can be transmitted from the transaction server40to the signing device30via e-mail, a proprietary protocol, an application-directed binary SMS message, etc. Alternatively, the signing device30can actively pull or extract the signing request60and transaction data64from the transaction server40.

As indicated above, the signing device30is configured to generate a digital signature (e.g., a digital signature value)70for a transaction and a user manually enters the transaction signature70, provided by the signing device30, into the client device20and submits the transaction signature70to the transaction server40to confirm the transaction. Such description is by way of example only. In one arrangement, the signing device30is configured to transmit the transaction signature70to the client device20such as by a Bluetooth, wireless, or WiFi connection between the client device20and the signing device30. The signing device30is configured to transmit the transaction signature70to the client device20by other wireless or optical connections such as an infrared connection.

As indicated above, the signing device30and the client device20are indicated as being physically separate devices. In one arrangement, the client device20and the signing device30form part of a single physical unit and include a virtual separation therebetween. In such an arrangement, it should be noted that the client device20and signing device30each maintain a correspondingly distinct communication channel22,24, respectively, with the transaction server40.

As indicated above, the signing device30is configured with a signing device application configured to generate the transaction signature70. In one arrangement, the signing device30does not include a signing device application. In such an arrangement, the transaction server40generates a digital signature value70derived from the transaction data52, session data for the user, the cryptographic key58such as a symmetric key, and nonce. The transaction data52is delivered over an encrypted connection to the first communication channel24. The signing device30is configured with a receiving application (e.g., e-mail, SMS, etc.) for viewing the transaction details and a signature value70. The user then enters the signature value70on the client device20as a confirmation of the transaction and transmits the signature value70to the transaction server40.

It should be understood that although various embodiments have been described as being methods, software embodying these methods is also included. Thus, one embodiment includes a tangible computer-readable medium (such as, for example, a hard disk, a floppy disk, an optical disk, computer memory, flash memory, etc.) programmed with instructions, which, when performed by a computer or a set of computers, cause one or more of the methods described in various embodiments to be performed. Another embodiment includes a computer which is programmed to perform one or more of the methods described in various embodiments.

Furthermore, it should be understood that all embodiments which have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded.

Finally, nothing in this Specification shall be construed as an admission of any sort. Even if a technique, method, apparatus, or other concept is specifically labeled as “prior art” or as “conventional,” Applicants make no admission that such technique, method, apparatus, or other concept is actually prior art under 35 U.S.C. §102, such determination being a legal determination that depends upon many factors, not all of which are known to Applicants at this time.