WO2012160037A1

WO2012160037A1 - System and method to efficiently identify transaction data to be signed in a signing device

Info

Publication number: WO2012160037A1
Application number: PCT/EP2012/059407
Authority: WO
Inventors: Amol Deshmukh
Original assignee: Gemalto SA
Current assignee: Thales DIS France SA
Priority date: 2011-05-25
Filing date: 2012-05-21
Publication date: 2012-11-29
Anticipated expiration: 2013-11-25

Abstract

Verification of transaction data using familiar names. A system and method for operating a security token to securing a transaction created by a user using a host computer. The security token receives a transaction message from the host computer over a communications link wherein the transaction message comprises an identifier identifying a party to the transaction. The token determines whether an entry for the identifier identifying a party to the transaction exists in a list of registered transaction parties. If the determination of whether an entry for the identifier identifying a party to the transaction exists in the list of registered transaction parties, displaying an indication that the party exists in the list of registered transaction parties. Other systems and methods are disclosed.

Description

SYSTEM AND METHOD TO EFFICIENTLY IDENTIFY TRANSACTION DATA TO BE SIGNED IN A SIGNING DEVICE

BACKGROUND OF THE INVENTION

[0001 ] The present invention relates generally to securing online transactions, and more particularly to securing online transactions signed using an optical token against attacks such as phishing, and man-in-the-middle and man-in-the-browser attacks.

[0002] Financial institutions of all sizes are currently evaluating their current security solutions and gauge their effectiveness against the rapidly changing threat landscape. Three types of attack that are of concern include Phishing, Man-ln-The-Middle (MITM) and Man-ln-The-Browser attacks.

[0003] Phishing and other social engineering attacks will always be a threat and should be addressed with ongoing consumer /employee education. The solutions that will provide real protection and survive a security review are those that can defend against sophisticated technology-based attacks that occur without the end user involvement.

[0004] A Phishing attack involves an attacker masquerading an email or website as belonging to a legitimate trustworthy online entity. Through the masquerading communication a user is baited into entering account credentials that the attacker may then use to obtain access to the user's account and thereby cause damage to the user, for example, by withdrawing funds from the account or causing payment to a third party.

[0005] In a Man-ln-The-Middle attack an attacker inserts himself between two communication endpoints, for example, between a client of a website and that website. The attacker mimics the behavior of each of the endpoints with respect to the other end-point such that both end-points think they are communicating directly with each other. By doing so, the MITM attacker can capture sensitive information transmitted between the two endpoints, such as account information. The Man-ln-The-Browser attack is closely related to the MITM attack. In the MITB attack, a Trojan is inserted into a browser, for example, as a browser extension or plug-in. This Trojan has the ability to modify transaction details exchanged between a user of the browser and a website. For example, in a transaction for transfer of funds, the user may believe he is transferring a certain amount from one account to another whereas the MITB Trojan modifies the transaction so that the bank transfers the funds to a third account.

[0006] To defend against Man-ln-The-Middle (MITM) and Man-ln- The-Browser (MITB) attacks, financial web sites must implement transaction- specific authentication in addition to user authentication. This is a move beyond the passive authentication used for most retail banking applications and many cash management applications, beyond one-time passwords (OTP), even beyond Challenge/Response (C/R) solutions. These solutions have provided security layers, but stop short of protecting online transactions from attack.

[0007] Transaction-specific authentication, also called transaction signing, is a method for verifying the integrity of the financial transaction. This ensures that online transactions received by the bank are exactly the transaction the customer intended to perform. In this model, the online customer is provided with a token which provides the ability for the customer to verify their transaction on the screen or display of the token itself.

[0008] One difficulty with transaction-specific authentication is the necessity for a user to enter account information accurately and the secure management of keys that may be used to sign transactions.

[0009] Secure personal tokens may be used to secure many online transactions. Such tokens, e.g. , smart cards, may be used to store account numbers, keys associated with account numbers, and to use this information to authenticate transactions.

[0010] For exam ple , a secure personal token may i ncl ude a customer's checking account number and a secret key associated with that account. When the customer wishes to make a payment from the checking account, the user may retrieve the account number from the secure personal token and direct the personal token to sign a transaction using the secret key.

[001 1 ] Optical readers, such as the Ezio Optical Reader from Gemalto S.A., Meudon, France, is an optical authentication device having an optical link that captures the data users would normally enter from a keypad to carry out and sign online transactions, eliminating cumbersome typing. A user presents the reader in front of their PC screen and the data needed for authentication and signature generation is instantly transmitted. The user is presented on a screen on the optical reader the information associated with thetransaction and is provided the option, on the optical reader, to proceed with or cancel the transaction.

[0012] While optical readers and secure personal tokens with transaction-specific authentication goes a long way towards securing online transactions, problems remain. Typical transaction data that is involved in a signature process is the Account number from where the money is to be debited from (FROM ACCT), the account number where the money will be transferred to (TO ACCT) and the amount of money that will be transferred (AMOUNT). When users are presented with transaction data to be signed, the FROM ACCT and TO ACCT are a sequence of numbers (like the IBAN - International Bank Account Number). It is difficult to read the long sequence of digits and make sure that these numbers, e.g., the TO ACCT has not been changed by a Trojan or MITM/MITB. Users have the tendency to get used to simply clicking "NEXT" and may inadvertently approve a transaction with fraudulent data.

[0013] Whi le the foregoi ng describes the problem of a user confirming transaction data that may have been modified by a Trojan in the context of optical readers and associated secure personal tokens, similar problems relate to other transaction mechanisms. For example, mobile telephones are becoming increasingly popular as a technology choice for online transactions. Such solutions are also vulnerable to MITM and MITB attacks and transaction-specific authentication may be used to combat such attacks. Thereto , a user may be cal l ed to authorize transaction data before a cryptographic signature is applied and the user may routinely confirm such transactions out of habit.

[0014] From the foregoing it will be apparent that there is still a need for an improved method to provide a mechanism by which users can easily verify that the transaction data prior to authorizing a security device to cryptographically sign a transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a schematic illustration of an online transaction secured using a security token and an optical reader.

[0016] Figure 2 is an illustration of a smart card inserted into an optical reader of Figure 1.

[0017] Figure 3 is an illustration of the backside of the optical reader of Figure 2 having several optical sensors located thereon.

[0018] Figure 4 is an illustration of a user placing an optical reader against the screen of a personal computer in anticipation of optical transmission from the personal computer to the optical reader.

[0019] Figure 5 is a smart card which may be used as personal security device.

[0020] Figure 6 is a block diagram il l ustrati ng an exam ple architecture for a personal security device of Figures 1 through 5.

[0021 ] Figure 7 is a series of instances of use of a personal security device with an optical reader, displaying an account number corresponding to each instance of use.

[0022] Figure 8 is a database schema for an account database containing familiar names for accounts used in online transactions.

[0023] Figure 9 is a series of instances of use of a personal security device with an optical reader, displaying familiar names rather than account nu mbers whenever an account nu mber of a transaction has a corresponding familiar name.

[0024] Figure 10 is a flow-chart illustrating one embodiment for registering familiar names.

[0025] Figure 1 1 is a flow-chart illustrating one embodiment for using familiar names to verify transactions more easily.

DETAILED DESCRIPTION OF THE INVENTION [0026] In the following detailed description, reference is made to the accom panying drawi ngs that show, by way of i ll ustration , specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in con nection with one em bodi ment may be i m plemented with i n other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, li ke numerals refer to the same or similar functionality throughout the several views.

[0027] In an embodiment of the invention, a technology is provided for allowing a user to easily verify transaction data prior to authorizing a personal security device, such as an optical reader with a security token or a mobile telephone, to cryptographically sign a transaction. The technology is simple, yet elegant, and provides an inexpensive way to add further level of security to online transactions.

[0028] Figure 1 , by way of example, is a schematic illustration of an online transaction secured using a security token and an optical reader. The process flow is as follows:

[0029] Step 1 : A user 101 inserts a personal security device 103 into an optical reader 105, and logs into the personal security device 103 using authentication credentials, e.g., PIN. In one embodiment, the personal security device 103 is a smart card and the optical reader 105 is an optical reader 105 specifically designed to receive and communicate with a smart card as shown in Figures 2 and 3. [0030] Figure 2 is an illustration of a smart card 201 inserted into an optical reader 105. The optical reader 105 has a small display 203 on which information for the user 101 may be displayed. The user may enter information using a keypad 205 of the optical reader 105. The display 203 may be used to display transaction data for the user's confirmation. The keypad 205 may be used for a user to enter information such as a PIN to log into the personal security device 103 (here the smart card 201 ; henceforth herein, the security device is referred to as personal security device 103. That is to be taken to include smart card 201 and other alternative embodiments).

[0031 ] Figure 3 is an il lustration of the backside of the optical reader 105 wherein several, here five, optical sensors 301 are located. These optical sensors 301 may receive transaction data from a screen on a user's personal computer, as illustrated in Figure 4 and discussed below.

[0032] Step 2: The user 101 places the optical reader 105 in front of the screen 107 of the user's personal computer 109. The user 101 lines up the optical reader 105 to a corresponding image on the screen 107 of the user's personal computer 109, as shown in Figure 4 which is an illustration of a user placing an optical reader 105 against the screen of a personal computer 109 in anticipation of optical transmission from the personal computer 109 to the optical reader 105.

[0033] I n Figure 4, a user 1 01 places the optical reader 1 05 against the screen 107 of the user's personal computer 1 09 l ined up with an image of the optical reader 105 and to couple of alignment marks 401 on the screen using corresponding alignment marks 403 on the optical reader 105. By thus aligning the optical reader 105, the optical sensors 301 are aligned with corresponding transmission areas 405. The transmission areas 405 are made to flicker in a manner that may be sensed by the optical reader 105 and processed by the optical reader 105 to digital data that may be used to transmit messages from a web application running via the personal computer 109.

[0034] The received di gital messages may be processed by the personal security device 103. As noted, in one embodiment, the personal security device 103 is a smart card 201 . A smart card 201 is illustrated in Figure 5. As seen there, the smart card 201 is typically a plastic card, for example, in the form factor of a credit card. Alternatively, the smart card 201 may be a SIM card inserted into a mobile communications device, e.g., a mobile telephone. The smart card 201 has a physical connector pad 501 for communicating to the optical reader 105. Alternative embodiments, e.g., USB form-factor smart cards would also have a physical connecter, e.g . , a U SB connector, for communication with the optical reader 105. In yet an alternative embodiment, the personal security device 103 is contained within the optical reader 105.

[0035] The personal security device 103 architecture is illustrated in Figure 6 which is a block diagram illustrating the architecture of one embodiment of a personal security device 103. The personal security device (PSD) 103 has a connector 501 for connecting the portable security device 103 to a optical reader 105. Alternatively, the personal security device 1 03 communicates wirelessly to the optical reader 105. The personal security device 103 further contains a processor 605 connected to a communications interface 617 for communication to the host computer via the connector 501 . The processor 605 is further connected to a non-volatile memory 607 and a read-only memory 609. The read-only memory 609 may be used to store programs 61 1 , for example, program instructions executable by the processor 605 to perform the methods described herein. These programs 61 1 may, alternatively, be stored in the non-volatile memory 607. The non-volatile memory 607 may further store an account database 615 for storing information related to accounts with which the user 101 uses the personal security device 103 and the optical reader 105 for transaction-specific authentication. This account database is described in greater detail herein below.

[0036] Returning now to the process flow of Figure 1 . To recap

Ste p 2 : As noted the user 1 01 pl aces the o pti cal reader 1 05 ( havi ng the personal security device 103 inserted therein or contained therein) against the screen 107 of the user's personal computer 1 09 in the manner shown in Figure 4.

[0037] Step 3: The transaction data is transmitted via the optical sensors 301 to the optical reader 105 and the personal security device 103. The transaction data is displayed on the display 203 as an indication to the user 101 to cryptographically sign the transaction data.

[0038] Step 4: The user 101 checks and validates the data.

[0039] Step 5: The personal security device 103 generates a one- time-password (OTP) that is captures the cryptographic signature of the transaction data. The OTP may be a hash that captures the cryptographic signature of the transaction data.

[0040] Step 6: Through the web browser window on the screen 107 of the user's personal computer 109, the user 101 enters a user ID and the OTP thereby indicating that the user has validated and authorized the corresponding transaction.

[0041] Step 7: The user ID and OTP are transmitted to an authentication server which validates the OTP.

[0042] Step 8: the validation result is transmitted back to the personal computer 109 of the user 101, and

[0043] Step 9: the validation result is displayed on the screen 107 of the user's personal computer 109.

[0044] Figure 7 is a series of illustrations of the display of transaction data on the optical reader 105, for example, corresponding to Step 3. The left hand column (instances 701a - 701c) illustrate an initial display of three account numbers, respectively, to a user. These could, for example, occur when the user 101 registers the personal security device 103 for use with the accounts or on an occasion when a user 101 attempts to make a transaction with the accounts.

[0045] The right hand column (instances 701a' - 701c') represents another occasion of use of the three accounts, respectively. The keen observer will notice that in the example of instance 701b' the account number is not exactly the same as for 701b, namely, the account number in 701b is "2658745923" whereas in 701b' the number is displayed as "2658746923," i.e., the seventh digit is a '6' rather than a '5.' Now, suppose that the first instance 701b is the actual account belonging to the user 101 and that the second instance 701b', has been modified by a MITM or MITB program. The user 101 is likely to not notice the difference in the account number and is likely to OK the transaction thereby generating an OTP that would confirm the transaction and entering that OTP to actually confirm the transaction.

[0046] In a preferred embodiment, a user 101 may enter familiar names associated with each account managed by the personal security device 103. These are entered into an account database 615 (introduced in conjunction with Figure 6).

[0047] Fig u re 8 is an i l l ustration of a database schem a for the account database 615. The Account Database 615, here illustrated as a relational database table, includes an Account Number field and a Familiar Name field. For each account of the user, a familiar name may be entered, e.g., "Amol's Checking" for account "1548964523" and "Texas Gas" for account "2658745923."

[0048] To d is p l ay th e accou nt n u m be r i n th e d is p l ay 203 , the personal security device 103 transmits the familiar name rather than the actual account number to the optical reader 105. Thus, when the account is displayed on the display 203, the fami liar name is displayed rather than the account number.

[0049] Fi g u re 9 is a seri es of i l l ustrati ons of the d ispl ay of transaction data on the optical reader 105, for example, corresponding to Step 3 wherein the familiar names are displayed rather than the account numbers. Note that for the instances 901 a and 901 b (corresponding to instances 701 a and 701 b of Figure 7), the familiar names, "Amol's checking" and "Texas Gas," are displayed rather than the corresponding account numbers. The user 101 would recognize these as familiar names for the accounts and would be comfortable with OKing the transactions. On the other hand, for the instance 901 b' (corresponding to the instance 701 b of Figure 7), the account number suggested by the web application is displayed. As noted in the discussion of Figure 7, this account number is incorrect. Because it does not match an account number in the database, the account number rather than the familiar name is displayed. The display of an account number serves as an alert to the user 101 that there is some issue with the account number and upon close inspection, the user 101 would realize that the account number is not the intended account number and, the user 101 would not OK the transaction.

[0050] Figure 10 is a flow chart illustrating the steps of registering a familiar name for an account number into the account database 615. The registration process may be performed via an application program running on the personal computer 109 and using the optical reader 105 for transmitting data to the personal security device 103.

[0051 ] The user 101 would select an account to manage, step A01.

[0052] The user 1 01 sel ects to e nte r a fam i l i ar na me for the account, step A03.

[0053] The user 101 enters a familiar name for the account, step

A05.

[0054] The user's entry of a familiar name for the account is transmitted to the personal security device 103, step A07.

[0055] The user's entry of a familiar name for the account is entered into the account database 615 on the personal security device 103, step A09.

[0056] Figure 1 1 is a flow chart illustrating the steps of using a familiar name for an account number entered into the account database to allow a user easier verification that a transaction is accurate.

[0057] A user 101 uses an optical reader 105 to sign a transaction in the manner of Figure 1 et seq, step B01.

[0058] The optical reader 1 05 reads the account number from the screen 107 of the user's personal computer 109, step B03.

[0059] The personal security device 103 retrieves the familiar name from the account database 615, step B05.

[0060] The familiar name, if there is such an entry in the account database 615 is displayed on the display 203 of the optical reader 105, step B07.

[0061 ] While the foregoing has been described in the context of using an optical reader 105 to transmit account information to a personal security device 103 other mechanisms are possible and those possibilities would benefit from the techniques described herein. For example, the reader for the personal security device 103 may communicate with the personal computer 109 using WIFI, Bluetooth, or USB to transmit account numbers to the personal security device 103 rather than the optical transmission described hereinabove.

[0062] While the foregoing has been described in the context of a personal security device 103 used in conjunction with an optical reader 105, the technique of displaying familiar names in lieu of account numbers is applicable in other scenarios. For example, one popular payment mechanism involves mobile telephones. The display on the mobile telephone may then be used to display transaction data. Just as in the case of the optical reader example, the display of account numbers may cause difficulty for a user to detect that account numbers are accurate as displayed. A familiar names account database may be used, in the manner discussed above, to display a familiar name rather than the account number thus making user verification of the account easier.

[0063] From the foregoing it will be apparent that a technology has been presented that in a simple, elegant, and extensible manner provides a user of a personal security device 103, for example, a smart card used with an optical reader or a mobile telephone, a mechanism by which the user more readily can verify that the transaction data presented to the personal security device 103 for cryptographic signature is accurate. This technology, therefore, provides a heightened level of security to online transactions, including providing a solution to man-in-the-middle and man-in-the-browser attacks.

[0064] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.

[0065] We Claim:

Claims

1. A method for operating a security token to securing a transaction created by a user using a host computer, comprising:

receiving, on the security token, a transaction message from the host computer over a communications link wherein the transaction message comprises an identifier identifying a party to the transaction;

determining whether an entry for the identifier identifying a party to the transaction exists in a list of registered transaction parties; and

if the determination of whether an entry for the identifier identifying a party to the transaction exists in the list of registered transaction parties, displaying an indication that the party exists in the list of registered transaction parties.

2. The method of Claim 1 wherein the identifier identifying a party to the transaction is an account number corresponding the party to the transaction.

3. The method of Claim 1 or 2 wherein the security token is an optical reader comprising an optical sensor and the communications link comprises an optical transmission from a screen, connected to the host computer, to the optical sensor.

4. The method of Claim 1 or 2 wherein the security token is a personal communications device, e.g . , a mobile phone, and wherein the communications link comprises a communications link between the personal communications device (for example, a WiFi link or via SMS) or any other token that can receive the communication from a transactional server.

5. The method of any of the preceding claims wherein the indication that the party exists in the list of registered transaction parties comprises displaying an alias for the identifier.

6. The method of Claim 5 wherein the alias is a familiar name associated with the party to the transaction.

7. The method of any of the preceding claims further comprising displaying a warning if the identifier identifying a party to the transaction does not exist in the list of registered transaction parties.

8. The method of any of the preceding claims further comprising computing a password for the transaction upon the user confirming accuracy of the transaction to the security token based on the displayed indication that the party exists in the list of registered transaction parties.

9. A security token comprising

a communications link by which the security token communicates with a host computer;

a processor connected to the communications link and to computer readable storage storing instructions executable by the processor to cause the processor to execute the method of any of Claims 1 through 8.

10. The security token of Claim 9 wherein the communications link comprises optical sensors.

1 1 . The security token of Claim 9 or 10 further comprising a user- interface device on which the indication that the party exists in the list of registered transaction parties is displayed and through which the user may confirm the transaction based on the indication that the party exists in the list of registered transaction parties.