Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction

Definitions

• the present invention relates to a method of secure data communication and to a system employing such a method.
• the present invention relates to a method of communicating data between a client terminal and a remote server which prevents effective unauthorised interception of the data being communicated and in the case of encrypted data therefore presents a negligible risk of the encrypted data being decoded.
• the present invention is particularly well suited, but not exclusively, to financial applications such as ATMs and online banking in which authorisation data for accessing secure financial data is transmitted by client terminals over potentially non-secure communication links to a remote server where the authorisation data is then verified.
• the identity of a user is generally verified through the use of authorisation data, e.g. usemame, password or a personal identification number (PIN), which is sent between the client terminal and the database server.
• authorisation data e.g. usemame, password or a personal identification number (PIN)
• PIN personal identification number
• measures may be taken by the user of a client terminal to ensure that the authorisation data remains secret, the authorisation data may nevertheless be observed by others as it is entered by the user or it may be electronically intercepted at some point between the client terminal and the database server.
• Unauthorised access to financial data such as a person's bank details, clearly carries financial rewards making it the target of increasing criminal activity.
• many credit or debit cards employ a magnetic strip or an electronic chip which carries part of the cardholder's authorisation data.
• the remainder of the authorisation data is known to the cardholder for example in the form of a PIN.
• the card is inserted into an automated teller machine (ATM) or credit card "PDQ" machine, the information stored on the magnetic strip or electronic chip as well as the PIN entered by the cardholder are passed to a remote database server, or a separate authorisation server, for verification. If the authorisation data is correct, the cardholder is granted access to his financial data.
• ATM automated teller machine
• PDQ credit card "PDQ" machine
• a simple form of card fraud is to observe the cardholder entering his PIN at an ATM and then to steal the card.
• the data stored on the card may be copied using publicly-available magnetic-card readers during financial transactions. The copied card may then be used to make purchases and cash withdrawals without drawing the attention of the cardholder or bank.
• Smart cards offer significant security advantages over magnetic-strip cards in that all authorisation data, including the PIN, are stored on the card in encrypted form. This makes card copying during financial transactions practically impossible. Moreover, if a card is stolen it is extremely difficult and time-consuming for criminals to access the PIN stored on the card. Nevertheless, card fraud is still possible by observing the cardholder entering his PIN and subsequently stealing the card. This form of card fraud is particularly relevant to smart cards in which a PIN, rather than a signature, is used for everyday electronic point-of-sale (EPOS) transactions. As a result, the chances of a cardholder's PIN being observed are increasing.
• EPOS electronic point-of-sale
• FR 2819067 describes an EPOS terminal for use with a smart card and comprises a touch-screen keypad. Each time a smart card is inserted into the EPOS terminal, a random keypad arrangement is displayed to the cardholder on the touch-screen keypad for entering his PIN. As a result, an observer is unable to determine a cardholder's PIN merely by observing the finger movement of the cardholder. Similar systems are described in US 5,949,348 and US 4,479,112. As the PIN of a smart card is stored on the card itself, EPOS transactions occur without the need to send the full authorisation data to the database or authorisation server. In particular, at no time is the PIN stored on the card communicated beyond the EPOS terminal. These publications do not therefore address the problem of others intercepting authorisation data during communications between the EPOS terminal and a remote database server.
• 'phishing' a relatively new trick employed by criminals to fraudulently obtain bank customers' bank authorisation data has become known as 'phishing'. This involves the sending of an email or letter to a bank's internet customers which directs the customers to a website that has the appearance of a webpage of the bank and which asks the customers to enter, in full, their authorisation data - usually on a pretext such as a routine security check.
• the website is, of course, false and the criminals operating the website are then able to capture and use the customers' authorisation data to arrange for funds to be transferred from the customers' accounts.
• a separate further object of the present invention is therefore to provide a method of authorisation which reduces the likelihood of customers being duped by fraudulent phishing attacks.
• the present invention provides a method of secure communication between a server and a terminal remote from the server, the terminal including a user operated data input device, the secure communication method comprising the steps of: communicating encoding data from the server to the terminal, the encoding data being specific to a communication event; generating positional data from data entered by a user using the data input device of the terminal with respect to the encoding data, the positional data consisting of identifiers for the positions of user selected characters of the data input device; communicating the positional data from the terminal to the server; and decoding the positional data received by the server using said encoding data to generate the user entered data.
• the present invention provides a secure communication system comprising a server and at least one terminal remote from and in bi-directional communication with the server, the server comprising: an encoder for generating encoding data specific to a communication event; a communications interface for communicating the encoding data to the remote terminal and for receiving positional data from the terminal, the positional data consisting of identifiers for the positions of user selected characters and being an encoding of user entered data; and a decoder for decoding positional data received from the terminal, the decoder using the encoding data of the encoder to decode the positional data, and each terminal comprising: a manually operated input device for the entry of user data that is encoded as positional data; and a terminal communications interface for receiving encoding data from the server and for communicating positional data to the server.
• the present invention provides a secure communication server comprising an encoder for generating encoding data specific to a communication event; a communications interface for communicating the encoding data to a remote terminal and for receiving positional data from the remote terminal, the positional data consisting of identifiers for the positions of user selected characters and being an encoding of user entered data; and a decoder for decoding positional data received from the terminal, the decoder using the encoding data of the encoder to decode the positional data.
• the present invention provides a method of secure communication between a server and a terminal remote from the server, the terminal including a user operated data input device and display, the secure communication method comprising the steps of: issuing a request for communication to the server from the remote terminal and providing to the server preliminary user identification data specific to the user of the terminal, identifying design data specific to the user and communicating display data from the server to the terminal based on the identified design data; and generating an image on the display of the terminal based upon the display data received from the server wherein further sensitive data is entered by a user only when the image on the display corresponds to an image previously made known to the user.
• the present invention provides a secure communication system comprising a server and at least one terminal remote from and in bi-directional communication with the server, the server comprising: user design data storage in which is stored display data specific to each user; and a communications interface for communicating the display data to the remote terminal and for receiving user entered data from the terminal, and each terminal comprising: a user operated data input device for the entry of user data; a display; and a terminal communications interface for receiving display data from the server and for communicating user entered data to the server.
• the present invention provides a secure communication server comprising: user design data storage in which is stored display data specific to each user; and a communications interface for communicating the display data to the remote terminal and for receiving user entered data from the terminal.
• FIG. 1 illustrates an authorisation system in accordance with the present invention
• Figure 2 is a simplified diagram of the data exchanges that are performed in accordance with a first embodiment of the data communication method of the present invention
• Figure 3 illustrates exemplary image data generated by the security server of the authorisation system of the present invention
• Figure 4 illustrates an alternative authorisation system in accordance with the present invention
• Figure 5 is a simplified diagram of the data exchanges that are performed in accordance with a second embodiment of the data communication method of the present invention
• Figure 6 illustrates exemplary image data employing alphanumeric characters generated by the security server of the authorisation system of Figure 4.
• Figure 7 illustrates exemplary image data employing non- alphanumeric characters generated by the security server of the authorisation system of Figure 4.
• the authorisation system of Figure 1 comprises a client terminal 1 , a database server 2 and a security server 3, all three of which are in bidirectional communication with one another.
• the security server 3 is absent and the client terminal 1 and database server 2 communicate only with each other.
• the client terminal 1 is adapted either in hardware or software to access data remotely stored on the database server 2 and to make changes and / or additions to the remotely stored data.
• the client terminal 1 includes a display 4 and an input device 5. Suitable devices for the client terminal include, but are not limited to, personal computers, ATMs, mobile phones and PDAs. Indeed, any device capable of external communications and having a display and an input device may be adapted to function as the client terminal 1.
• the display 4 of the client terminal 1 may be any device capable of modifying its appearance in order to convey varying information to a user. Whilst a VDU is preferred, the display 4 could alternatively consist of modifiable legends on a keypad or keyboard such that the display 4 and input device 5 are integral. Alternatively, the display 4 and input device 5 may be integrated in the form of a touch-screen display.
• the input device 5 is used to input authorisation data, such as a usemame, password and / or PIN.
• This authorisation data is subsequently used by the client terminal 1 to gain access to the database server 2.
• the client terminal 1 may additionally include means for receiving and reading a card, or other identification means, carrying partial authorisation data.
• the client terminal 1 may be an ATM in which case the card reader of the ATM receives a card carrying the account details of the cardholder, e.g. name, bank sort code and account number.
• the data carried on the card represents only part of the authorisation data and access to the database server 2 is only granted when additional authorisation data is entered by the user on the input device 5 of the client terminal 1.
• the database server 2 stores data 10 intended to be accessed only by authorised personnel and includes means 6 for verifying the authorisation of a user attempting to access the database server 2.
• the verification means 6 in its simplest form comprises a look-up table containing a list of valid authorisation data. If the authorisation data received by the verification means 6 matches valid authorisation data stored in the look-up table, the user is granted access to the data 10 stored on the database server 2.
• the verification means 6 is adapted to determine the identity of the user from the received authorisation data such that access to the data stored on the database server 2 may be tailored according to the identity of the user, e.g. such that a patient is only able to access his own medical records, or a bank customer is only able to access his own bank details.
• the verification means 6 may be part of the database server 2 or it may take the form of a separate authorisation server which gates access to the database server 2 until valid authorisation data is received.
• the security server 3 comprises a combination generator 7, an image generator 8 and a decoder 9.
• the combination generator 7 is adapted to generate a random string and an identification code specific to that random string.
• the random string that is generated will depend upon the content of the authorisation data to be entered by the user on the input device 5 of the client terminal 1 with randomisation occurring over the legitimate character set. For example, if the authorisation data is in the form of a PIN, i.e. if the authorisation data includes only numerals, the random string is ideally 10 characters long, e.g. 7260948135'.
• the random string may be up to 36 characters long corresponding to 10 numerals (0-9) and 26 letters (A-Z), e.g. 'JR6VSAPKB2G...'
• the combination generator 7 communicates both the random string and the identification code to the image generator 8 and to the decoder 9, and communicates only the identification code back to the database server 2.
• the random string may be generated, for example, by selecting at random, e.g. using a random number generator, an entry from a look-up table of character strings, each character string having a different configuration.
• the image generator 8 takes the random string received from the combination generator 7 and generates image data suitable for display on the client terminal 1.
• the image data may consist of an image file (e.g. JPG, GIF, BMP etc) or an HTML file.
• the generated image comprises at least each character of the random string, wherein the position of each character in the image is determined by the order in which that character appears in the random string. So for example, the first character of the random string may be displayed at the top left of the image whilst the last character of the string is displayed on the bottom right of the image.
• the generated image preferably retains the same overall design regardless of the random string of characters that is received, and it is only the configuration of the characters within this same overall design that changes with each random string.
• the image generator 8 might always generate the image of a numerical keypad, in which the arrangement of the numerals on the keypad is changed according to the random string that is received.
• Figure 3 illustrates possible image data generated by the image generator 8 upon receiving the string "35492*0#6781".
• the image data generated by the image generator 8 should be understood to be any data which the client terminal 1 can use to change the appearance of the display 4.
• the display 4 comprises configurable legends on a keypad
• the image data might comprise nothing more than the random string received from the combination generator 7.
• the client terminal 1 on receiving the image data would then modify the legend of the first key of the keypad to display the first character of the random string, modify the legend of the second key to display the second character of the string and so on.
• the image data generated by the image generator 8 for a particular random string is assigned the same identification code as that received from the combination generator 7 for that random string. Accordingly, with each request that is received from the database server 2, the security server 3 generates image data and assigns that image data an identification code. The identification code is sent from the security server 3 to the database server, which in turn communicates the identification code to the client terminal 1.
• the client terminal 1 uses the identification code to retrieve the corresponding image data generated by the image generator 8 from the security server 3.
• the client terminal 1 uses the received image data to modify the appearance of the display 4 so as to present the user with a plurality of characters (e.g. numerals, letters and symbols etc) whose positions are arranged randomly.
• a user then enters his authorisation data by selecting the individual characters making up his authorisation data, such as a PIN, using the input device 5.
• the authorisation data entered by the user is recorded as positional data by the client terminal 1. This positional data may then be converted by the client terminal 1 into character data or some other form of data for sending to the security server 3.
• positional data might be 'first-row-first-column, third-row-first-column, third-row-second- column, second-row-first -column'.
• This positional data might then be converted to "1 ,7,8,4", which corresponds to the arrangement of numerals on a conventional numerical keypad.
• positional data or the character data to which it may be converted represents an encoded form of the authorisation data.
• This encoded authorisation data e.g.
• the decoder 9 stores each random string and identification code that is received from the combination generator 7. When the encoded authorisation data and the identification code are received from the client terminal 1 , the decoder 9 decodes or extracts the true authorisation data using the corresponding random string, i.e. the random string having the same identification code. The decoded authorisation data is then sent from the decoder 9 of the security server 3 to the database server 2.
• the client terminal 1 first sends a request (S1 ) for access to the database server 2.
• This request may be performed by establishing a connection between the client terminal 1 and the database server 2.
• the user may first be required to input partial authorisation data, e.g. a username. If the partial authorisation data is valid then this constitutes a request for access.
• the database server 2 issues a request (S2) for a terminal display identification code from the security server 3.
• the database server 2 may also acknowledge the client terminal's request for access by communicating to the client terminal a transaction identification code specific to this access request. This transaction identification code is different from the identification code requested from the security server.
• the combination generator 7 then generates a random string and a terminal display identification code (S3), both of which are communicated to the image generator 8 and the decoder 9.
• the image generator 8 then generates image data (S4) suitable for display on the client terminal 1 and assigns the image data the same terminal display identification code.
• the terminal display identification code is sent from the security server 3 to the database server 2, which in turn sends the identification code to the client terminal 1 (S5). Accordingly, the client terminal 1 receivers from the database server 2 a unique transaction identification code specific to the transaction in progress and also a terminal display identification code. The client terminal 1 then uses the terminal display identification code to request image data from the security server 3 (S6). The image data generated by the image generator 8 specific to that particular identification code is then returned by the security server 3 to the client terminal 1 where it is displayed.
• the user then enters his authorisation data (S7) using the image data presented on the client terminal 1. Owing to the random arrangement of characters displayed on the client terminal 1 , the authorisation data entered by the user is encoded.
• the encoded authorisation data and the terminal display identification code are then sent (S8) from the client terminal 1 to the security server 3 where they are received by the decoder 9.
• the decoder 9 decodes the encoded authorisation data (S9) using the terminal display identification code to identify the corresponding random string that has been used to encode the authorisation data.
• the true authorisation data is communicated (S10) from the security server 3 to the database server 2.
• the true authorisation data is then checked by the verification menas 6 (S 11 ) and if the verification means 6 determines that the authorisation data received from the security server 3 is valid, access to the database server 2 is granted to the user (S12). Otherwise, the database server 2 communicates to the client terminal 1 that the authorisation data was invalid (S13) and in accordance with current banking practice invites the user to re-enter his PIN up to a maximum of three attempts. If invalid, the database server 2 may additionally request a new terminal display identification code from the security server 3 which will also result in turn with new image data being delivered to the client terminal 1 , so as to begin the process anew.
• the image data retrieved from the security server 3 by the client terminal 1 serves as the code for encoding the authorisation data entered by the user.
• the data entered by the user is immediately encoded, i.e. the user in effect enters encoded authorisation data.
• the client terminal 1 need not therefore separately encode data entered by the user.
• the client terminal 1 does not receive and then encode the true authorisation data entered by the user. Instead, the user, without knowing, enters encoded authorisation data.
• encoded authorisation data may be achieved through the use of a dumb terminal, i.e. a terminal 1 comprising nothing more than display means 4 and input means 5.
• the security server 3 may issue to the client terminal a 'virtual map' in which the positions of specific keys of the keyboard e.g. the alphanumeric sequence, are each allocated their own identifier. Each position identifier is selected to be different to the actual character of that key on the keyboard. Thus, where the identifiers are alphanumeric symbols, in effect the virtual map swaps around characters for the individual keys of the keyboard.
• the virtual map By employing the virtual map to communicate a user's keystrokes to the security server, although the user's keyboard remains the same and the authorisation data is entered in the usual manner, the authorisation data entered by the user which is communicated back to the security server 3 is encoded in the form of positional data with respect to the virtual map.
• This system is particularly suited for example to circumstances such as the use of a home pc when conducting on-line banking.
• identification codes enable multiple client terminals 1 to access the database server 2 and the security server 3 simultaneously.
• the use of identification codes may be omitted should the authorisation system be set-up such that only one user, or client terminal 1 , is capable of accessing the database server 2 at any one time. In this case, identification codes are not needed since only one random string is generated and used by the security server 3 at any one time.
• Each identification code may consist of, or include, a URL to a website.
• the image data generated by the image generator 8 is then stored in the form of a web document, e.g. HTML or XML file or Java applet etc.
• a unique and temporary URL is returned to the client terminal 1 in response to a request from the client terminal 1 for access to the database server 2.
• the client terminal 1 uses the URL to load the contents of the relevant website to display the image data.
• the URL preferably includes no data that would enable spoofing.
• the corresponding random string stored in the decoder 9 is preferably deleted from the security server 3.
• a person intercepting the encoded authorisation data is unable to resend this encoded data to the security server 3 in order to gain access to the database server 2.
• the security server 3 may be configured to issue an alert of a potential security breach.
• the image data generated by the image generator 8 is also preferably deleted after the security server 3 receives the encoded authorisation data.
• the image data and/or random string may have a limited lifetime for example 5 minutes which is sufficient for most ATM transactions. As a result, the user may be timed-out should he take too long in entering his authorisation data.
• the authorisation data is never sent un-encoded from the client terminal 1.
• the encoded authorisation data sent by the client terminal 1 is encoded using a random string, it is extremely difficult if not impossible for others intercepting only the encoded data to extract the authorisation data.
• the authorisation data is entered by selecting characters having a random configuration, it is significantly more difficult for a person observing a user to visually acquire the user's authorisation data.
• the communication link between the database server 2 and the security server 3 is itself secure, e.g. by means of an internal or dedicated line that is not accessible externally. Consequently, there is no need to encode the authorisation data sent between the secure server 3 and the database server 2.
• the decoder 9 of the security server 3 preferably re-encodes the decoded authorisation data using a one-way-hashing algorithm before sending the hashed authorisation data to the database server 2.
• the verification means 6 of the database server 6 instead stores only hashed authorisation data. This additional step of hashing the authorisation data has the added security that authorisation data is never stored in un-encoded form on either the database server 2 or the security server 3. Consequently, anyone compromising the security of either server 2,3 is unable to extract authorisation data.
• all communications within the authorisation system i.e. between servers 2,3 and with the client terminal 1 , are preferably encrypted using 128 bit SSL protocol, for example.
• the two datastreams have no common data to enable an observer to determine the datastreams are related to the same account.
• Illicit acquisition of authorisation data by intercepting both the image data and the encoded authorisation data sent between the client terminal 1 and the security server 3 can be undermined by further improving the security of the authorisation system by encrypting the image data and the encoded authorisation data with different encryption keys.
• the task of decrypting the data to obtain the authorisation data is more than doubled. This is because the task of decryption becomes increasingly difficult as the size of the encrypted data decreases.
• the image data may comprise little more than a random string of characters (e.g. the numerals 0-9) and the encoded authorisation data may comprise little more than a few select characters (e.g.
• the size of the data to be encrypted is typically only a few tens of bytes.
• the encrypted data is extremely resistant to brute force methods of decryption.
• the security server 3 may include two servers, the first server storing the image data generated by the image generator 8 and the second server storing the encoded authorisation data received from the client terminal 1. The client terminal 1 then requests image data from the first server, which is encrypted using a first key, and sends the encoded authorisation data to the second server using a second encryption key.
• the authorisation system preferably includes a separate database server 2 and security server 3
• the combination generator 7, the image generator 8 and the decoder 9 may all form part of the database server 2.
• the security server 3 is omitted and the client terminal 1 communicates only with the database server 2.
• the database server 2 upon receiving a request for access from the client terminal 1 , returns an identification code and image data to the client terminal 1.
• the client terminal 1 then sends the encoded authorisation data and identification code to the database server 2, whereupon the encoded authorisation data is decoded and its validity verified.
• the database server 2 may include two servers employing different encryption keys for separately communicating the image data and the encoded authorisation data.
• the first server is responsible for receiving a request for access from the client terminal 1 and returning the identification code and image data
• the second server is responsible for receiving the encoded authorisation and identification code from the client terminal 1.
• the authorisation system may be used in any situation in which authorisation needs to be verified remotely.
• the authorisation system may be used to gain access to a secure building.
• the client terminal 1 may be a keypad adjacent a door and the database server 2 upon receiving valid authorisation data from the security server 3 sends a signal to the door to open.
• the authorisation of a user may be verified remotely, across potentially non- secure communications, in a more secure manner than is presently possible.
• the authorisation of the user may be verified without data being sent by the user which, if intercepted, could be used to extract the user's authorisation data.
• Figure 4 A further development of the authorisation system and method described above is illustrated in Figure 4; the system is similar to the system illustrated in Figure 1 and like reference numerals have been used where appropriate. This further development is particularly suited for use with a client terminal 1 having a display such as an LCD, plasma or CRT display.
• the database server 2 additionally includes a look-up table 11 in which is stored a list of users or customers with each user assigned a design code such as an alphanumeric string which is preferably, but not necessarily, unique to an individual user.
• a display data decoder 12 is additionally provided in the security server 3 .
• the display data decoder 12 is programmed to decode the design codes of each user and to communicate the design data to the image generator 8.
• the design data defines features of the image to be displayed by a client terminal when the user of the terminal is prompted to enter their authorisation data such as their PIN number.
• the webpage that is presented to each user is tailored and is preferably unique to each user.
• the same user is always presented with the same webpage but the design of the webpage varies between users. Examples of what the design data may define are: the font size of the lettering / numbering on the webpage; the background colour of the webpage; the colour of the individual selectable keys; the colour of a border around the keys; the shape of the individual keys; the shape of any border around the keys; as well as any decorative details such as patterning or additional images.
• Figure 5 illustrates a webpage with a rectilinear patterned border to an alphanumeric electronic keypad. It will, of course, be apparent that the design variations of the webpage are not limited to the examples given above and that there are an extremely large number of features the design of which can vary without detracting from the function of the webpage which is to enable a user to enter their authorisation
• the remote terminal 1 requests access (S20) to the database server 2.
• the database server 2 informs the remote terminal of the session id for this communication session and prompts the remote terminal for preliminary identification of the user requesting access. This could be the user's name or their account number, for example.
• the remote terminal 1 communicates the identification information with the session id to the database server 1.
• the database server 2 identifies from the look-up table 11 the design code for that user (21 ) and communicates the design code to the security server 3 with a request for a new session (S22).
• the security server 3 determines from the design code (23) the design features for the log-on page specific for that user.
• a randomised arrangement of the individual button of the keypad is generated (24), as described above with reference to Figure 2.
• the image generator 8 then creates a log-on page (S25) employing the user's design features and communicates the URL for that log-on page along with a separate session id specific to communication session concerning that user between the database server and the security server (S26).
• the database server 2 then communicates the URL to the remote terminal 1 which accesses the URL (S27) and displays the particular log-on webpage for that user.
• the user's authorisation data is then entered (S28) and communicated by the remote terminal 1 in its encoded form as a result of the re-arrangement of the keypad to the security server 3 (S29).
• the security server 3 subsequently decodes the positional key data (S30) to identify the user's true authorisation data which is then communicated to the database server 2 (S31 ) using the session id unique to the communication session between the database server and the security server.
• the database server 2 compares (S32) the authorisation data received from the security server 3 with the authorisation data it already has recorded for that user. Assuming the authorisation data is correct, the database server 2 then grants access (S33) to the secure system requested by the user at the remote terminal 1 or refuses access (S34) where the authorisation data is incorrect.
• the necessary authorisation information is broken up into segments and different segments are exchanged between different communication combinations of the remote terminal, the database server and the security server.
• No single communication exchange contains all the identification and authorisation data.
• the individual data packets, each of which is preferably encrypted, are not large enough to enable someone to crack the encryption using current code-cracking techniques.
• the identification and authorisation data are broken up into at least two segments with each segment employing a different session id and a different communication link. It is envisaged that a user may be given the opportunity to select their own design variations which are then stored in the look-up table 11 of the database server 2. However, this would require the full range of design variations to be publicly available. It is therefore preferred that the design variations are selected by the bank so that the available permutations are kept secret.
• This familiarity with their own, preferably unique, webpage means that if an attempt is made to obtain a user's authorisation data by phishing, the user will be presented with a webpage that does not include the design details with which the user has become familiar. This enables a user to distinguish between a valid webpage issued by the bank and a phishing webpage.
• the authorisation system of Figure 1 was described with respect to the need for a series of individually numerically labelled keys or buttons to be displayed.
• the present invention envisages the option of the keys or buttons to be individually labelled with a mixture of numbers and letters as illustrated in Figure 6.
• the log-on webpage would present an arrangement of a plurality of keys, for example a 3 x 4 array, which does not include a key for each possible number or letter.
• the webpage will include the numbers and letters the user needs to enter their authorisation code.
• FIG. 7 cartoons or image thumbnails of any distinguishable character can be employed with the authorisation system.
• the keys include cartoon images of a lorry, a cloud, a flower, a cup etc. These characters are in addition to the distinctive design of the keypad as a whole which in this case involves a border of adjacent circles.
• the user selects the three or four keys from the array of keys which constitute their authorisation data.
• the authorisation data comprises 1) car, 2) raincloud, 3) sun and 4) flower-pot.
• the individual keys of the display may be each allocated a separate sound, preferably a brief description of the character of the key. A user will then be permitted to tab across the keys to hear the different sounds without the keys being selected. On hearing a key specific to the user's authorisation code, a user will then be able to select the key by pressing the enter button on their keyboard, for example.
• the system may be adapted so that keys are only selected if the same key is selected twice successively. So that the first selection of a key by the user only triggers an audio description of the key, repeating the selection thereafter would then treat the key as selected for the purposes of the user's authorisation code.
• this invention is intended to encompass alternative procedures for enabling a user to hear the different sounds associated with the keys without key selection for the purposes of entering the user's authorisation data.
• the present invention additionally offers to users having sight disabilities the benefit of electronic access to secure data, such as home banking, previously unavailable to them.
• the authorisation systems of the present invention thus offer significantly improved security over known electronic log-on systems as they break up the identification and authorisation data into a plurality of segments with at least one of the segments being communicated under a different identifying session code to that of another segment and / or a different communications link.
• the authorisation system of Figure 4 additionally offers a significantly reduced risk that a customer or user might be misled into entering their authorisation data to a phishing site. As phishing scams are believed to have cost banks and credit-card companies losses of around $10.2 billion in 2003 the need for this security risk to be addressed is currently acute.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Finance (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Telephonic Communication Services (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Storage Device Security (AREA)
• Computer And Data Communications (AREA)
• Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Priority Applications (7)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34451837

Family Applications (1)

Country Status (10)

Cited By (7)

Families Citing this family (13)

Citations (4)

Family Cites Families (2)

• 2005
  • 2005-03-07 GB GBGB0504545.5A patent/GB0504545D0/en not_active Ceased
• 2006
  • 2006-01-06 CN CNA2006800155612A patent/CN101180662A/zh active Pending
  • 2006-01-06 BR BRPI0608576-8A patent/BRPI0608576A2/pt not_active Application Discontinuation
  • 2006-01-06 WO PCT/GB2006/050002 patent/WO2006095203A1/en not_active Application Discontinuation
  • 2006-01-06 CA CA002602861A patent/CA2602861A1/en not_active Abandoned
  • 2006-01-06 IN IN2389MUN2014 patent/IN2014MN02389A/en unknown
  • 2006-01-06 EA EA200701906A patent/EA200701906A1/ru unknown
  • 2006-01-06 AU AU2006221804A patent/AU2006221804B2/en not_active Ceased
  • 2006-01-06 JP JP2008500278A patent/JP2008537210A/ja active Pending
• 2007
  • 2007-09-04 IL IL185709A patent/IL185709A/en active IP Right Grant

Patent Citations (4)

Also Published As

Similar Documents

Legal Events