JP2018519562A - Method and system for transaction security - Google Patents

Abstract

  The transaction includes one or more messages that are transmitted to the transaction server via the first communication channel. Each transaction message includes at least one item of important transaction data. A method for securely processing a transaction includes transmitting (606) a first transaction message to a transaction server via a first communication channel. Thereafter, one-time security data is generated that defines one or more actions to be performed based on the key transaction data to generate a transaction verification code (608). The one-time security data (402, 403) is transmitted to the user via a second communication channel that is functionally distinct from the first communication channel. The transaction server receives a second transaction message over the first communication channel that includes a first transaction verification code provided by the user in response to receiving the one-time security data over the second communication channel. To do. The second transaction verification code is generated by performing an action defined by the one-time security data based on the key transaction data included in the received first transaction message, and the first transaction verification code Is compared (616) with a second transaction verification code. If there is a mismatch between the first transaction verification code and the second transaction verification code, the transaction request is rejected (622).

Description

  The present invention relates to information security, and more particularly to enhancing the security of important data exchanged over a communications network, including but not limited to financial transaction details exchanged over the Internet. .

  Two-factor authentication (TFA) is generally used to authenticate communications performed via a communication network including the Internet. In basic authentication, a requesting entity (eg, a user) presents some evidence of his identity to a second entity (eg, a service provider such as a bank). The use of TFA reduces the chance that the requesting entity will present false evidence for its identity by requesting two different types of evidence, or elements, from a finite list, such as pre-approved elements Let Typically, a TFA has three possible elements: what the requester knows (eg PIN or password), what the requester has (eg ATM card or registered mobile phone), And requesting the requesting entity to provide two of the user's own (eg, fingerprint or other biometric information).

  One general category of TFA generally converts a user's mobile phone to a token device using SMS messaging, automated phone calls, or a dedicated application running on the user's smartphone. A typical example is an internet banking system that allows a user to sign a bank's online portal using personally identifiable information (eg, username and password) on a personal computer or other internet-enabled device. This identification information is a knowledge factor in the TFA scheme. If the user registers the mobile phone number with his online banking service in advance, the mobile phone can act as an ownership factor. According to some such systems, a mobile phone number with a randomly generated verification code registered when a user requests a transaction (eg, fund transfer or payment) via internet banking. In order to confirm and approve the transaction completion, it must be entered into the internet banking interface.

  In the above embodiment, SMS messaging is used as a back channel to send a verification token independent of the main communication channel between the user and the internet banking portal. Therefore, an unauthorized user needs not only the authentic user identification information but also the authentic user's mobile phone to complete the unauthorized transaction. However, such a TFA method may be vulnerable to attacks that damage the main communication channel itself. In particular, such authentication techniques may be vulnerable to man-in-the-middle (MIM) attacks and man-in-the-browser (MIB) attacks. The mechanism by which these attacks operate is shown in FIGS. 1a, 1b and 2.

  As shown in the block diagram 100 of FIG. 1 a, a user 102 accesses a secure service portal (SSP) 106, such as an Internet banking portal, via the Internet 108, for example, using a desktop PC 104. use. Web browser software 110 runs on PC 104 and provides a graphical interface to the user. The web browser 110 generally connects to a local network along with network interface software (protocol stack) that implements the various communication protocols necessary to exchange information with other devices via one or more communication networks. The Internet 108 is accessed through a network interface 112 that includes both the physical hardware necessary for the network.

  However, in scenario 100, the user's PC 104 is damaged, for example, by some form of malware, and the browser 110 is not directly connected to the Internet banking portal 106, but instead is connected to the unauthorized MIM server 114. This can be done by tricking the user to click on a redirect link to the fraudulent site 114 such that the authentic host name of the internet banking portal 106 is mapped to the IP address of the fraudulent server 114, or a domain name service It can be achieved by damaging the network interface configuration of the PC 104 such as a (domain name service: DNS) sub-system.

The fraudulent server 114 provides a website that is a close copy or an exact copy of the internet banking website provided by the portal 106. Typically, a secure connection with the portal 106 is required so that SSL TLS (ie, HTTPS protocol) is used to authenticate the server and encrypt all communications. As a result, the user 102 can receive a warning regarding a mismatch between the digital certificate provided by the fraudulent server 114 and the obvious domain, ie, that of the user's banking service provider. However, many users can ignore or overlook such warnings.

  Even this security level can be damaged, for example, by the MIB attack shown in block diagram 120 of FIG. 1b. In the MIB attack, the malicious software application 122 enters the user's PC 104 and is itself interposed between the browser interface 11 and the network interface 112. MIB malware directly accesses all data transmitted to or from the browser interface 110, thereby independent of any encryption and authentication performed between the network interface 112 of the PC 104 and the Internet banking portal 106. In particular, information communicated between the user 102 and the internet banking portal 106 can be read and / or modified.

  FIG. 2 shows an attack mechanism timeline 200 in the MIM or MIB scenario shown in FIGS. 1a and 1b. In the illustrated example, the user first enters 202 transaction details that may include the transfer amount ‘a’ and the payee account number ‘A’. A transaction request is sent 204, but MIM / MIB 114/122 intercepts. The fraud service modifies the request, for example, changes the transaction amount to a higher value 'b' and the payee account to an unauthorized account number 'B'. Such a modified transfer request is received via the internet banking portal 106 and the transaction details are verified 208 by the bank server. The internet banking portal 106 then returns 210 a confirmation page that includes the transaction details including the fraudulent amount 'b' and the payee account 'B'. These are modified by the malware and re-insert the user requested amount 'a' and the payee account 'A' and sent 212 to the browser 110 to update 214 its display. At this point, the user is unaware that the transfer actually requested on the internet banking portal 106 is different from the transaction request originally entered.

  At the same time, the bank server generates a verification code 216 and transmits the code to the user's mobile phone via a back channel 218, such as an SMS messaging channel. The user receives the verification code 220 and enters 222 the verification code on the confirmation page displayed by the web browser 110. A confirmation code is then sent 224, transmitted on 226 by the MIM / MIB 114/122 malware, received by the bank server and validated 228. This allows the fraudulent transaction amount 'b' to account 'B' to be validated and approved, after which the internet banking portal 106 provides a further transaction confirmation page 230. The malware 114/122 can modify the confirmation page 232 again to hide fraudulent transactions. In fact, the sophisticated malware 114/112 allows the user over his / her internet banking session to delay the discovery of fraudulent transactions until the time funds can be withdrawn or transferred from the fraudulent account 'B'. It will then present consistent false information.

  As can be appreciated from the foregoing embodiments, improved transaction security that can prevent or at least mitigate the risks associated with MIM, MIB, and other attacks based on a damaged primary communication channel What is needed is a method and system. The present invention is directed to providing such improvements.

In one aspect, the present invention provides a method for securely processing a transaction that includes one or more transaction messages that are transmitted to a transaction server via a first communication channel and that include at least one item of significant transaction data. And the above method is:
Receiving a first transaction message corresponding to a user's transaction request including an item of significant transaction data by a transaction server via a first communication channel;
Generating one-time security data defining one or more actions to be performed based on the key transaction data to generate a transaction verification code in response to receiving the first transaction message;
Transmitting the one-time security data to a user via a second communication channel that is functionally distinct from the first communication channel;
A second transaction message including a first transaction verification code provided by a user in response to receiving the one-time security data via a second communication channel is received by the transaction server via the first communication channel. Step to do;
Generating a second transaction verification code by performing the operations defined by the one-time security data based on the key transaction data included in the received first transaction message;
Comparing the first transaction verification code with the second transaction verification code; and rejecting the transaction request if there is a mismatch between the first transaction verification code and the second transaction verification code; including.

  Advantageously, embodiments of the present invention provide a technical arrangement in which a verification code can be generated at two remote locations, eg, independently from an end user location and a security system location. The verification code is in at least one item of the key transaction data so that any modification of key transaction data can be detected as a mismatch in the independently generated verification code during transmission over the first communication channel. Dependent. The second channel is used to transmit one-time security data that is used to generate a verification code. As a result, breaching the security provided by embodiments of the present invention requires intrusion of both the first and second communication channels. In particular, an MIM or MIB attacker who has infiltrated the first channel with which the primary transaction message is exchanged responds to modified critical transaction data such as the destination bank account number in the absence of access to the second channel. An accurate verification code cannot be generated reliably.

  According to an embodiment of the present invention, the one-time security data includes a security matrix including a mapping between each symbol in the symbol set associated with the key transaction data and a code value randomly selected from the code set; Thereby, the operations performed based on the key transaction data include generating a replacement code by substituting one or more symbols of the key transaction data with an associated code value defined by the mapping. The security matrix may only be valid for the duration of the transaction.

  Use of security matrix mapping, for example from code sets (eg upper case, lower case, and complete set of numbers) to corresponding random selection of symbols, symbols containing important transaction data (eg important data account number The use of the numbers '0' to '9') advantageously allows the user to generate a verification code without technical assistance, which simply uses a matrix to account number Is to map the specified number of to the corresponding code symbol. Thus, the security data can be transmitted over a second channel including, for example, a cellular mobile network link via SMS messaging.

  The one-time security data can further include supplemental security data that defines one or more additional actions to be performed on the replacement code to generate a transaction verification code. For example, one or more additional actions defined by supplemental security data can include selecting a subset, such as a symbol of a replacement code, for inclusion in a transaction verification code. An example of supplemental security data is a specification that defines selected numbers of account numbers used to generate a verification code. Advantageously, the use of supplemental security data provides a challenge level for an intruder on the first communication channel when trying to derive or guess an accurate verification code corresponding to the changed critical transaction data. To increase.

  In an embodiment of the present invention, the transaction verification code may be derived from a hash of code that is generated by performing the operations defined by the one-time security data based on the key transaction data.

In some embodiments, the one-time security data is transmitted to the user device via the second communication channel for processing by a software application executing on the user device. Software applications are:
Receiving one-time security data via a second communication channel;
Requesting and receiving from the user important transaction data necessary for the generation of a transaction security code by means of an action defined in the one-time security data via the user interface of the user device;
Generating a transaction verification code by performing the actions defined by the one-time security data based on the key transaction data received from the user; and generating the generated transaction verification code via the user device user interface And providing to the user.

  For example, a software application ['app'] may be configured to run on a smart device (eg, a user's smartphone or tablet). The app then receives security data via a functionally differentiated second communication channel, prompts the user to provide key transaction data (eg, account number), generates a transaction verification code, A human readable representation of the transaction verification code can be displayed. Thus, certain benefits derived from the use of the app can make the actions performed based on the key transaction data entered by the user more complex, which allows the user to do without advantageous technical assistance. It is potentially safer than a set of more limited actions that can actually be performed. A further advantage is that it can reduce the occurrence of human errors.

In another aspect, the present invention provides a computer server system including a processor coupled to a memory store that includes executable program instructions, when the executable program instructions are executed by the processor:
Providing a secure service portal accessible to a user via a first communication channel and configured to facilitate transactions in response to a user transaction request;
Responsive to receiving a first transaction message corresponding to a user's transaction request that includes an item of important transaction data via a first communication channel, based on the important transaction data to generate a transaction verification code. Generating one-time security data defining one or more actions to be performed;
A first transaction verification code provided by the user in response to receiving one-time security data transmitted to the user via a second communication channel that is functionally distinct from the first communication channel; Receiving a second transaction message including: via a first communication channel;
Generating a second transaction verification code by performing the operations defined by the one-time security data based on the key transaction data included in the received first transaction message;
Comparing the first transaction verification code with the second transaction verification code; and rejecting the transaction request if there is a mismatch between the first transaction verification code and the second transaction verification code; To execute.

In some embodiments of the invention, when the executable program instructions are executed, the processor:
One-time security data is generated by sending a request for generation of one-time security data over a secure communication channel to a security system configured to generate the one-time security data.

  Advantageously, using a separate security system to generate security data allows the associated security services to be used in multiple server systems without having to duplicate the overall security function in each server system. To. End users can also register with a single security system provider and establish relevant user preferences with a single security system provider. User preferences can include preferences that modify or determine the manner of operations performed based on key transaction data to generate a transaction verification code. This method provides an additional level of security in that even if two transactions are protected by the same security data, different transaction preference codes can be derived by applying different user preferences. Can be done.

In some embodiments, the executable program instructions cause the processor to generate a second transaction verification code when executed:
Sending a first transaction verification code to a security system configured to generate one-time security data via a secure communication channel; and a first transaction verification code and a received first transaction A response message including a display of a comparison result with a second transaction verification code generated by a security system that performs an action defined by the one-time security data based on the key transaction data included in the message The first transaction verification code and the second transaction verification code are compared by receiving from the security system via a secure communication channel.

In a further aspect, the present invention provides a security system that includes a processor coupled to a memory store that includes executable program instructions, when the executable program instructions are executed by the processor:
Receiving a request for generation of one-time security data from a remote processor via a secure communication channel;
Generating one-time security data defining one or more actions to be performed based on key transaction data of the user's transaction to generate a transaction verification code;
Sending a security message containing one-time security data to the user's device via a communication back channel;
Receiving a first transaction verification code generated by a user based on the key transaction data and provided to the remote processor via the primary communication channel from the remote processor via a secure communication channel;
A second transaction verification code is obtained by performing an action defined by the one-time security data based on the key transaction data contained in the transaction message sent by the user to the remote processor via the primary communication channel. Generating;
Comparing a first transaction verification code with a second transaction verification code; and securely communicating a response message including an indication of a comparison result between the first transaction verification code and the second transaction verification code Transmitting to the remote processor via the channel.

  Executable program instructions, when executed, cause the processor to send a security message including one-time security data to the user's device via the remote processor.

In yet another aspect, the present invention provides a portable computing and communication device that includes a processor coupled to a memory store that includes executable program instructions, the executable program instructions being executed by the processor when executed. :
Receiving one-time security data via an associated communication channel defining one or more actions to be performed based on key transaction data to generate a transaction verification code;
Presenting the user with a prompt to enter important transaction data via the portable computing and communication device user interface;
Receiving important transaction data from the user via the user interface;
Generating a transaction verification code by performing actions defined by one-time security data based on critical transaction data; and presenting a human-readable representation of the transaction verification code to the user via a user interface To do and to do.

  Executable program instructions, when executed, may cause the processor to generate a transaction verification code according to a method that includes computing a hash of the converted key transaction data.

In yet another aspect, the present invention provides a computer program product comprising a computer readable medium having executable program instructions stored therein, wherein the executable program instructions are connected to an associated communication channel. When executed by the processor:
Receiving one-time security data via an associated communication channel defining one or more actions to be performed based on key transaction data to generate a transaction verification code;
Presenting the user with a prompt through the user interface to enter important transaction data;
Receiving important transaction data from the user via the user interface;
Generating a transaction verification code by performing the actions defined by the one-time security data based on the key transaction data; and presenting a human-readable representation of the transaction verification code to the user via the user interface To do and to do.

  Further details on the operating principles of the present invention, as well as various applications and configurations, and the advantages and advantages associated therewith, will be understood from the disclosure of the various embodiments as follows. However, these embodiments are provided by way of example and are not intended to limit the overall scope of the invention as defined in any one of the above descriptions or in the appended claims. Absent.

Embodiments of the present invention should be described with reference to the accompanying drawings, wherein like reference numerals indicate like features.
FIGS. 1a and 1b are block diagrams illustrating meson (MIM) and man-in-the-browser (MIB) scenarios according to the prior art, respectively. FIG. 2 is a diagram showing an attack timeline based on the MIM / MIB exploit according to the prior art. FIG. 3 is a block diagram illustrating an exemplary system architecture for implementing the present invention. FIG. 4 is a diagram showing a timeline for generating and exchanging verification codes for realizing the present invention. FIG. 5 is a timeline for communication between a secure service portal (SSP) and a security system implementing the present invention. FIG. 6 is a flowchart showing a transaction security method for realizing the present invention. FIG. 7 is a diagram illustrating an exemplary screen display of a smart device application implementing the present invention. FIG. 8 is a schematic diagram of a system for establishing a reliable back channel between a secure service provider and a smart device application implementing the present invention.

  FIG. 3 is a block diagram illustrating a system 300 that implements the present invention. A public communications network 108, such as the Internet, is used for messaging between client devices 304 and secure service portal (SSP) 106. Generally speaking, client device 304 is any suitable computing or processing device that has the ability to communicate over the Internet 108 using, for example, web browser software and / or other connected applications. obtain. Similarly, other components shown in system 300 including SSP 106 typically include one or more processing, computing and / or storage devices. In this specification, terms such as 'processor', 'computer', etc. are understood to refer to various possible implementations of a device or apparatus including a combination of hardware and software, unless the context requires otherwise. It should be. This includes cooperating hardware and software platforms that can be co-located or distributed, including single processor and multiprocessor devices and apparatus. The hardware can include ordinary personal computer architectures or other general purpose hardware platforms. The software can include commercially available operating system software combined with various applications and service programs. Alternatively, the computing or processing platform can include custom hardware and / or software architecture. For improved scalability, the computing and processing system can include a cloud computing platform that allows physical hardware resources to be dynamically allocated in response to service requests. Although all of these variations are within the scope of the present invention, for ease of explanation and understanding, the exemplary embodiments described herein are single processor general purpose computing platforms, generally utilized. Based on possible operating system platforms and / or widely available consumer products such as desktop PCs, notebook or laptop PCs, smartphones and the like.

  Software components that implement the features of the present invention may be developed using any suitable programming language, development environment, or combination of language and development environment, as is familiar to those skilled in the software engineering field. For example, suitable software can be used to implement network or web-based services such as C programming language, Java programming language, C ++ programming language, and / or JavaScript, HTML, PHP, ASP, JSP, etc. It can be developed using a variety of suitable languages. It will be appreciated that these examples are not intended to be limiting and that other convenient languages or development systems may be used in accordance with system requirements.

  In the exemplary system 300, the SSP 106 includes a processor 312. The processor 312 is interfaced to or otherwise operatively coupled to the non-volatile memory / storage device 314. The non-volatile storage device 314 can be a hard disk drive and / or can include solid-state non-volatile memory such as read only memory (ROM), flash memory, and the like. The processor 312 is also interfaced to a volatile storage device 316 such as a random access memory (RAM) that contains program instructions and temporary data related to the operation of the SSP 106.

  In a normal configuration, the storage device 114 maintains known programs and data content regarding the normal operation of the SSP 106. For example, the storage device 314 can include operating system programs and data, as well as other executable application software required for the intended function of the SSP 106. The storage device 314 also includes program instructions that when executed by the processor 312 direct the SSP 106 to perform operations relating to one embodiment of the transaction security system according to the present invention. In operation, instructions and data held on the storage device 314 are transferred to the volatile memory 316 for execution upon request.

  The processor 312 is also operatively coupled to the communication interface 318 in the normal manner. Communication interface 318 facilitates access to public data communication network 108.

  In use, the volatile storage device 316 includes processes and operations that implement the features of the present invention, including the various functional elements of the system, as will be described below with particular reference to the timelines shown in FIGS. Includes a corresponding body 320 of program instructions configured to execute.

  The SSP 106 further includes a further network interface 322 that provides access to the private network 324 that is used to securely communicate with other elements of the system 300 that are not intended to be directly accessible via the public network 108. be able to. The private network 324 can be physically distinguished from the public network 108 or can be implemented as a virtual private network (VPN) that physically uses the infrastructure of the public network 108. The network interface 322 is a virtual network interface that can share hardware components with the public network interface 318. Thus, the term 'network interface' as used throughout this specification exchanges information with other devices via one or more corresponding physical or virtual communication networks unless specifically required by context. It will be understood that it refers to a combination of physical hardware and / or network interface software (protocol stack) that implements the various communication protocols required to achieve this.

  As shown in system 300, SSP 106 can communicate with security system 326 via private network 324. Security system 326 is also a server platform shown in simplified form in the block diagram of FIG. Security system 326 includes a processor 328 that is interfaced to, or otherwise operatively associated with, additional non-volatile memory / storage device 330. The processor 328 is also interfaced to a volatile storage device 332 that contains program instructions and temporary data relating to the operation of the security system 326.

  The processor 328 is operatively coupled to a communication interface 334 that can communicate with the SSP 106 via the private network 324.

  In use, the volatile storage device 332 is configured to perform processes and operations that implement the features of the present invention, including various functional elements of the system described below, particularly with reference to the timeline of FIG. Corresponding body 336 of the programmed program instructions.

  The general function of the security system 326 is to receive requests from the SSP 106 and generate one-time security data that can be used for generation of strong verification codes against MIM and MIB attacks. In some embodiments, the one-time security data includes a verification matrix or table, as described in more detail below with reference to FIG.

  Security system 326 maintains a database of user account information, for example, in non-volatile storage device 330. This user database includes a record for each end user of system 300, ie, the user operating client appliance 304. Each user record includes a unique user identifier (ID) and an associated keyword or password. The user record also includes user preferences related to the use of the security system 326 and the use of all secure systems, devices and services such as the SSP 106 that use the services provided by the security system 326. For example, the use of a security system having features corresponding to system 326 for user authentication (eg, secure login) is disclosed in commonly assigned US Pat. No. 8, granted on October 21, 2014. 869,255.

  The private network 324 is also connected to a telecommunications service provider network 338, such as a public switched telephone network (PSTN), through a network termination unit (NTU) 340. This allows SSP 106, security system 326, and / or any other system connected to private network 324 to participate in communication with the end user via PSTN 338. Such communications can include voice telephone calls, automatic telephone calls, and SMS messaging. In exemplary system 300, PSTN 338 is shown connected to cellular mobile base station 342 that facilitates communication with end-user mobile device 344 also accessing SSP 106 via client device 304. ing.

  Thus, according to the system 300, an end user can provide a primary or primary communication channel between the client device 304 and the SSP 106 over the public network 108 that can provide a secure service, such as an Internet banking service. Have. In addition, there is a secondary channel (also called a back channel) that connects a secure system on the private network 324 to the end user device 344 via the PSTN 338. This back channel is one-time as described in more detail with reference to FIG. 4 so that any MIM, MIB, or other damaged entity located in the main channel is not accessible via the public network 108. It can be used to send security data, for example a security matrix or table.

  Turning now to FIG. 4, a timeline 400 illustrating verification code generation and exchange that implements the present invention is shown. The transmissions in the timeline 400 correspond to the back channel transmission 218 and the following main channel confirmation transmissions 224, 226, as shown in the prior art implementation 200 of FIG.

  According to embodiments of the present invention, instead of generating a fixed verification code that is sent to the end-user client device over the back channel, the SSP 106 issues a request to the security system 326 to generate one-time security data. To do. In the example shown in FIG. 4, a one-time security matrix or table 402 is generated, which includes a set of K key symbols (shown in the top row of table 402) and N code symbols (bottom row of table 402). Mapping) to the corresponding set of This mapping is substantially random or pseudo-random and cannot be predicted in advance by the SSP 106 or by any other entity in the example system 300. In this example, the one-time security data also includes supplemental security data 403, the purpose of which will be described later.

  In requesting the generation of security data 402, the SSP 106 identifies the corresponding user of the client device 304 so that the security matrix 402 can be generated according to any relevant user's preferences as well as according to the requirements of the SSP 106. can do. User and / or SSP preferences or requirements are specific number of attributes such as K key symbols on the top row, etc., and numbers and attributes such as code symbols used for mapping on the bottom row of table 402 Can include such matters as In general, N can be less than, equal to, or greater than K, and the mapping between key symbols and code symbols need not be unique, ie, code symbols can be reused. Embodiments of the present invention generate a corresponding fraud verification code without intercepting the security matrix 402 by an MIM or MIB attacker that can intercept the corresponding verification code (eg, generated as described below). Try to greatly reduce the possibility of being able to.

  According to embodiments of the present invention, the key symbol set is selected to correspond to one or more key component elements of the user's transaction. For example, in the case of Internet banking transfers, the recipient account number is important because if the money can be tampered with by an MIM / MIB attacker, the funds can be transferred to an unauthorized account. Assuming that the account number consists of digits between ‘0’ and ‘9’, such a set of digits includes the key symbol set in the upper row of the matrix 402. The user may then be required to generate a verification code based on some or all digits of the important payee account number. The code is generated by replacing each digit of the account number with the corresponding code symbol from the bottom row of the security matrix 402. Further, supplemental security data 403 identifies the four digit numbers (7th, 8th, 10th and 11th) of the payee account number used to generate a verification code for the transaction.

  Further, the user may perform some operations on account numbers (ie, key symbols) and / or code symbols while generating a verification code according to the relevant user preferences maintained by security system 326. it can. Such operations and preferences will be described in more detail below, but in this example, a simple case of direct mapping between key symbols and code symbols is described.

  The exact format in which the security matrix mapping 402 is sent to the end user is not critical and can depend on the attributes of the back channel. For example, the user device 344 can display information in a graphic format, in which case the security matrix 402 can be transmitted in the corresponding graphic format. Alternatively, if the back channel is an SMS back channel, it is more convenient to send the representation of the security matrix 402 to a text format, eg, '0 = X; 1 = a; 2 = Q; It can be.

  Regardless of the format in which the security matrix 402 is transmitted, the timeline 400 shows the generation of verification codes according to the one-time security data 402, 403 and payee account number (345-001 91561822). As indicated at 404, the corresponding verification code includes the seventh, eighth, tenth and eleventh digits ('9', '1', '6' and '7') of the account number in the matrix 402. Corresponding symbols, ie, 'haMs' obtained by mapping to 'h', 'a', M, 's'. This verification code is entered into the confirmation screen presented by the user on his web browser and transmitted 406 via the main channel.

  The code is intercepted by the MIM / MIB 114/122 that simply passes this code via transmission 408, without any change, according to the normal embodiment. However, the code passed from transmission 406 to transmission 408 does not match the account number originally received by SSP 106 because MIM / MIB 114/122 pre-modified the payee account number to tamper with the transaction. Thus, when the SSP 106 receives the verification code 404 and attempts to verify the validity, this validity verification should fail and an unauthorized modification of the key transaction information will be detected. Also, even if the MIM / MIB attacker 114/122 notices that the security matrix mapping system has been used, in order to obtain the one-time security data 402 and 403, it is illegally modified without access to the back channel. A verification code cannot be generated to match the received payee account number. Thus, the system and method embodying the present invention can prevent existing MIM / MIB attacks, as shown and described above in connection with FIGS. 1a, 1b and 2, or at least It can be greatly relaxed.

  FIG. 5 shows a timeline 500 illustrating communication between the SSP 106 and the security system 326 according to an embodiment of the present invention. The transmission shown in the timeline 500 occurs before and after the exchange shown in the timeline 400 of FIG. These transmissions allow the SSP 106 to take advantage of the services provided by the security system 326 to generate the security matrix 402 and validate the verification code received again from the end user. However, as can be appreciated, the security system 326 need not be implemented as a remote service separate from the SSP 106. All functions shown and associated with security system 326 may alternatively be implemented as a component of SSP 106. However, the embodiment of security system 326 as a remote service has the advantage that at least the associated security service can be used by multiple SSPs 106 without the entire function needing to be replicated in each case. End users can also use the same account and preferences across multiple SSP providers after registering with a single security system provider and establishing their associated user preferences in database 330.

  As shown in timeline 500, when SSP 106 receives the requested transaction details that require validation, it generates a request 502 that is sent to security system 326. This request may identify any additional information or parameters required by security system 326 to generate compatible one-time security data. For example, the request 502 can include the user's identification so that the security system 326 can incorporate any relevant user preferences from the database 330 into the generation of the security matrix. The request 502 can also include any parameters supplied by the SSP 106 specified in such a specific validity verification request. For example, if the one-time security data includes a security matrix, the parameters can be a key symbol set that can only contain digits between '0' and '9' for validity verification based on the payee account number. Identification can be included. However, in other contexts, the transaction information used to generate the verification code may be such as an account name so that the key symbol set is larger, including all alphabetic characters and selected special characters, for example. Things can be included. Further, the request 502 can include a parameter defining a number N such as a code symbol set and / or symbols to be used for the code symbol set.

  Upon receipt of the request 502, the security system 326 generates a corresponding security matrix and a response 504 containing that matrix is transmitted. Thereafter, SSP 106, or other components of system 300, will use the security matrix returned in response 504 to generate a message that is sent to the user device 344 over the back channel to the user.

  The user then generates and enters a verification code 404 that is retransmitted to the SSP 106 as shown in the timeline 400. The SSP 106 then generates a further request 506 for the security system 326. This further request 506 is for the security system 326 to validate the verification code received over the primary channel and return a further response 508 indicating whether the verification code is successfully validated. That is. The message 506 sent to the security system 326 may include parameters necessary for the security system 326 to validate the verification code. These parameters may include the user's identification, the returned verification code itself, and the relevant transaction details used to generate the verification code, such as the payee account number, or other important information. Thereafter, the security system 326 may record that record of the one-time security data that was previously generated and returned via the response 504, along with the transaction details, to regenerate the verification code to be entered and returned by the end user. And any relevant user preferences retrieved from the database 330. The locally generated verification code can then be compared to the code included in request 506 to determine whether the transaction is validated. The result of the comparison is returned in response 508. Thereafter, the SSP 106 can determine whether to execute the transaction according to the validity verification result 508.

  As described above, in some embodiments of the present invention, a user can be registered with security system 326 and executed on key symbols and / or code symbols to generate verification code 404. It can have associated user preference data stored in a user account record that defines additional operations. A non-exhaustive list of possible operations that can be provided to the user and that can be stored in his / her account record is listed below, and generally suitable operations for modifying the verification code are described by security system 326. Including a subset of operations available when also configured to provide an authentication (eg, secure login) service as described in co-assigned US Pat. No. 8,869,255. it can. Indeed, in some embodiments, the security system 326 may initially authenticate the user for multiple purposes, eg, as part of a login process, and subsequently validate the transaction requested by the user. Can be used by the SSP 106. In this manner, the MIM / MIB attacker 114/122 may also be prevented from obtaining the user's password during the initial login process.

Operations that can be provided by user preferences include:
Positive offset, ie the increment applied to each code value when generating the verification code 404 (if necessary, the number can be wrapped so that 9 + 1 = 0, the character is Z + 1 = Can be wrapped to be A);
A negative offset, ie a decrement applied to each code value (reverse wrapping can be used if necessary);
An increment is applied to each code value as a positive offset, but the magnitude of the increment itself is increased by each element of the verification code, an incremental positive increment, or positive 'crawl';
A decrement is applied to each code value as a negative offset, but the magnitude of the decrement is increased by each element of the verification code; and / or • used to formulate the verification code A mask that identifies a subset of code values within the overall code to be performed (thus, the mask performs a similar function as the supplemental security data 403 described in the previous embodiment, but 'per transaction ) Run on a 'per-user' basis, not on a 'standard').

  Referring now to FIG. 6, a flowchart 600 illustrating a transaction security method implementing the present invention corresponding to the timeline and general system architecture described above is shown.

  In step 602, the user authenticates with the SSP 106. This authentication can include signing in to the SSP 106 using identification and authentication information such as a user ID and password. Optionally, the authentication process can be made more secure by using the services of security system 326 in a manner as described in US Pat. No. 8,869,255.

  In step 604, the user wishes to perform a transaction and enters transaction details including important details such as payee account number and transaction amount, for example, in the case of funds transfer via an internet banking portal. In step 606, the transaction details are sent to the SSP 106, at which time they are exposed to potential interception by the MIM / MIB attacker 114/122.

  In step 608, one-time security data is generated, for example, via interactions 502, 504 between SSP 106 and security system 326. The resulting security data is transmitted over the back channel.

  In step 610, the SSP 106 generates a confirmation page that includes functionality for the user to enter a verification code and provides it to the end user. The user determines an appropriate verification code according to the security data, key transaction details, and any applicable user preferences, and then enters the code at step 612.

  In step 614, the verification code entered by the user is sent to the SSP 106, at which time it is subject to potential interception and retransmission by the MIM / MIB attacker 114/122.

  In step 616, the verification code is validated via interactions 506, 508 between the SSP 106 and the security system 326, for example, as shown in FIG. Depending on the validity verification result, the transaction is confirmed or rejected at step 618.

  While the description of the above embodiment serves to illustrate the principles of the present invention, it will be understood that many variations are possible, including variations that provide additional convenience to the end user. . For example, a user of a 'smart device' such as a smartphone or tablet may be provided with a dedicated application (or 'app') to assist in generating a verification code. For example, communications can be received on behalf of a user from a dedicated app, SSP 106 and / or security system 326. These communications are based on, for example, secret information (eg, secret keys) known only via SMS from a trusted caller number, or only by security system 326 and properly secured code elements within the app. May be received over a secure encrypted channel that may be established over the Internet or some other communication network.

  FIG. 7 shows an exemplary screen display of a smartphone app that implements the present invention. The user can open the app and start running the app before initiating a transaction with the SSP 106, or the app can be automatically opened upon receipt of the security matrix information 402 by monitoring the back channel. be able to. At this time, the display 700 may indicate that the user is prompted to enter the relevant transaction details, for example, the internet banking fund transfer recipient account number, via the text entry box 702. Having this information along with the received security matrix data, the app can present the verification code to the user for computing and entering the confirmation page, ie, step 612 of process 600. A corresponding exemplary screen display 704 provides a verification code 706 corresponding to the user.

  In embodiments where the user uses a smartphone app or the like to generate the verification code 706, more complex operations are used than would be appropriate when the user needs to generate the verification code manually. Can be done. For example, the app may include a security matrix 402 and / or other one-time security data that specifies the actions to be performed to convert an item of significant transaction data (eg, payee account number 702) into a corresponding verification code 706. Can be received. The operation can include computing a hash of the transformed key transaction data using, for example, MD5, SHA-1, SHA-2, or other known hashing algorithms, and the verification code is Can be derived from the computed hash. In this case, since it is not computationally valid for the MIM / MIB attacker to derive the original transformed key transaction data from the verification code, the attacker determines the transformation applied to the key transaction data. Is impossible. Thus, the MIM / MIB attacker would not be able to generate its own verification code that matches any fraudulently modified critical transaction data.

  FIG. 8 is a schematic diagram of a system 800 for establishing a trust back channel between a secure service provider and a smart device app that implements the present invention. As shown, the security system 326 with which the app communicates has an associated secret key 806 that is securely stored so that it cannot be accessed by any potential attacker. The corresponding public key 804 is via a trusted app store 808, such as Apple App Store or Google Play, which ensures that the app originated from its official source. Pre-loaded into the smart device app 806 to be made available to the end user and not modified or tampered before downloading to the end user device 810. Once executed on the end user device 804, the app generates a unique encryption key, encrypts it using the pre-loaded public key 804, and sends the encrypted encryption key to the security system 326. Can do. Such a unique encryption key can then be used for symmetric encrypted communication between the security system 326 and the user smart device 804. To enhance security, the symmetric encryption key can be frequently replayed by the app on the user device 804 as needed, and can be specifically replaced after each use.

  In an alternative embodiment, information pre-loaded into an app available from trusted app store 802 is unique to the security system 326 so that the app can recognize incoming SMS messages originated by the security system 326. Phone number.

  While particular embodiments and variations of the invention have been described herein, it will be appreciated that further modifications and alternatives will be apparent to those skilled in the relevant art. In particular, these examples and the like are provided to illustrate the principles of the invention and provide a number of specific ways to implement the principles. In general, embodiments of the present invention rely on providing a technical arrangement where verification codes can be generated independently at two remote locations, eg, at an end-user location and a security system location, where verification The code depends on at least one item of key transaction data so that any modification of key transaction data in transit over the primary communication channel can be detected as a discrepancy, such as in an independently generated verification code To do. An arrangement implementing the present invention uses a secondary channel to transmit one-time security data used to generate the verification code from the security system location to the end user location. Thus, systematically damaging the security provided by embodiments of the present invention requires intrusion of both primary and secondary communication channels.

  Accordingly, the described embodiments are to be understood as being provided by way of example for the purpose of teaching general features and principles of the invention and as defined in the appended claims. It should not be understood as limiting the scope of the invention.

Claims (15)

As a method of securely processing a transaction that is sent over a first communication channel to a transaction server and that includes one or more transaction messages that include at least one item of important transaction data:
Receiving a first transaction message corresponding to a user transaction request including an item of significant transaction data by the transaction server via the first communication channel;
Generating one-time security data defining one or more actions to be performed based on the key transaction data to generate a transaction verification code in response to receiving the first transaction message;
Transmitting the one-time security data to the user via a second communication channel that is functionally distinct from the first communication channel;
A second transaction message including a first transaction verification code provided by the user in response to receipt of the one-time security data over the second communication channel via the first communication channel. Receiving by the transaction server;
Generating a second transaction verification code by performing the operation defined by the one-time security data based on the important transaction data included in the received first transaction message;
Comparing the first transaction verification code and the second transaction verification code; and if there is a mismatch between the first transaction verification code and the second transaction verification code, the transaction request And a step of rejecting.   The one-time security data includes a security matrix including a mapping between each symbol in the symbol set associated with the key transaction data and a code value randomly selected from the code set, and based on the key transaction data The method of claim 1, wherein the operation performed comprises generating a replacement code by substituting one or more symbols of the key transaction data with an associated code value defined by the mapping.   The method of claim 2, wherein the security matrix is only valid for the duration of the transaction.   The one-time security data further comprises supplemental security data defining one or more additional actions to be performed on the replacement code to generate the transaction verification code. Method.   The one or more additional actions defined by the supplemental security data include selecting a subset, such as a symbol of the replacement code, for inclusion in the transaction verification code. Method.   The method of claim 1, wherein the transaction verification code is derived from a hash of a code generated by performing an operation defined by the one-time security data based on the key transaction data. The one-time security data is transmitted to the user device via the second communication channel for processing by a software application executing on the user device, the software application:
Receiving the one-time security data via the second communication channel;
Requesting and receiving from the user the critical transaction data required for the generation of the transaction security code by an operation defined in the one-time security data via a user interface of the user device;
Generating a transaction verification code by performing an action defined by one-time security data based on important transaction data received from a user; and generating the transaction verification code in the user interface of the user device The method of claim 1, wherein the method is configured to perform providing to the user via A computer server system including a processor connected to a memory store that includes executable program instructions, when the executable program instructions are executed, the processor:
Providing a secure service portal accessible to a user via a first communication channel and configured to facilitate a transaction in response to the user's transaction request;
In response to receiving a first transaction message corresponding to the user's transaction request including an item of important transaction data via the first communication channel, the important transaction to generate a transaction verification code. Generating one-time security data defining one or more actions to be performed based on the data;
In response to receiving the one-time security data transmitted to the user via a second communication channel that is functionally distinct from the first communication channel, a first provided by the user Receiving a second transaction message including a transaction verification code via the first communication channel;
Generating a second transaction verification code by performing the operations defined by the one-time security data based on the key transaction data included in the received first transaction message;
Comparing the first transaction verification code and the second transaction verification code; and in the case of a mismatch between the first transaction verification code and the second transaction verification code, A computer server system that performs the refusal. When the executable program instructions are executed, the processor:
Generating the one-time security data by transmitting a request for generation of the one-time security data to a security system configured to generate the one-time security data via a secure communication channel; The computer server system according to claim 8. The executable program instructions, when executed, cause the processor to generate the second transaction verification code:
Transmitting the first transaction verification code to a security system configured to generate the one-time security data via a secure communication channel; and the first transaction verification code and the received first Comparison result between the second transaction verification code generated by a security system that performs the operation defined by the one-time security data based on the important transaction data included in one transaction message 9. The first transaction verification code and the second transaction verification code are compared by receiving a response message including an indication of via a secure communication channel from a security system. Computer server system. A security system including a processor connected to a memory store that includes executable program instructions, when the executable program instructions are executed, the processor:
Receiving a request for generation of one-time security data from a remote processor via a secure communication channel;
Generating one-time security data defining one or more actions to be performed based on key transaction data of the user's transaction to generate a transaction verification code;
Sending a security message including the one-time security data to the user's device via a communication back channel;
Receiving a first transaction verification code generated by the user based on the critical transaction data and provided to a remote processor via a primary communication channel from the remote processor via the secure communication channel;
By performing the operations defined by the one-time security data based on key transaction data included in a transaction message sent by the user to a remote processor via the primary communication channel. Generating a transaction verification code;
Comparing the first transaction verification code with the second transaction verification code; and a response including an indication of a comparison result between the first transaction verification code and the second transaction verification code Sending a message to the remote processor via the secure communication channel.   12. The executable program instructions, when executed, cause the processor to send the security message including the one-time security data to the user's device via the remote processor. Security system. A portable computing and communication device that includes a processor connected to a memory store that includes executable program instructions when the executable program instructions are executed by the processor:
Receiving one-time security data via an associated communication channel defining one or more actions to be performed based on key transaction data to generate a transaction verification code;
Presenting a prompt to the user to enter the key transaction data to the user via the portable computing and communication device user interface;
Receiving the important transaction data from a user via the user interface;
Generating the transaction verification code by performing the operations defined by the one-time security data based on the key transaction data; and a human-readable representation of the transaction verification code for the user interface A portable computing and communication device for performing the presenting to the user.   14. The portable computation of claim 13, wherein the executable program instructions, when executed, cause the processor to generate the transaction verification code according to a method that includes computing a hash of transformed key transaction data. And communication devices. A computer program product comprising a computer readable medium having executable program instructions stored thereon, wherein when the executable program instructions are executed by a processor connected to an associated communication channel, the processor:
Receiving one-time security data via an associated communication channel defining one or more actions to be performed based on key transaction data to generate a transaction verification code;
Presenting the user with a prompt through the user interface to enter the key transaction data;
Receiving the important transaction data from the user via the user interface;
Generating the transaction verification code by performing the operations defined by the one-time security data based on the key transaction data; and a human-readable representation of the transaction verification code for the user interface A computer program product for performing to the user.

Images