System and method for cross coupling risk analytics and one-time-passcode

Abstract

To provide systems and methods for validating an action using a physical token, such as a near-field-communications (NFC)-capable chip.SOLUTION: A transaction verification server may receive a request to perform an action. A user of a client who owns a physical token may log into a mobile device application using their login credentials, scan the physical token with an NFC reader on a client device, which provides two-factor authentication (2FA). The scan may reveal a value for a counter on the physical token, which may be compared to a counter at the transaction verification server in order to validate that the physical token has been used as expected. If the server deems it appropriate, additional authentication may be required, such as scanning a photographic identification of the user.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 16 / 675,172, filed November 5, 2019, which is a continuation-in-part of U.S. Patent Application No. 16 / 205,119, filed November 29, 2018, which in turn claims priority from U.S. Provisional Application No. 62 / 740,352, filed October 2, 2018, the disclosure of which is incorporated herein by reference in its entirety.

[0002] TECHNICAL FIELD The present disclosure relates to cryptography, and more particularly to systems and methods for cryptographic authentication of contactless cards. [Background technology]

[0003] Data security and transaction integrity are critical to businesses and consumers, and this need continues to grow as electronic transactions comprise an ever-larger share of commercial activity.

[0004] When a suspicious or questionable transaction is processed, verification of the transaction may be required. Traditionally, this may involve sending a message to the user via email or short message service (SMS) requesting the user to confirm their intent to engage in the transaction.

[0005] These services are not only cumbersome, but may not provide a sufficient level of security as they are vulnerable to attacks. Furthermore, if a user stores their card together with their mobile device (e.g., if they store both in a wallet, or if they store the card in a wallet that is often co-located with the mobile device), an unauthorized attacker may gain possession of the device used to authenticate the transaction. [Brief explanation of the drawings]

[0006] [Figure 1A]1 illustrates an environment suitable for use with an exemplary embodiment. [Figure 1B] 1 shows an example of a contactless card with a physical token. [Figure 1C] 1 illustrates the structure of an exemplary physical token. [Figure 2A] 1 illustrates an exemplary interface of a mobile application associated with a contactless card owner. [Figure 2B] 1 shows an exemplary interface when a physical token is read by a reader on the owner's mobile device. [Figure 2C] 1 shows an example of data exchange between a contactless card and a client device. [Figure 3] 1 illustrates an exemplary data structure of a message between a contactless card and a client device or between a client device and a remote server, according to one embodiment. [Figure 4] 1 illustrates an example of data exchange between a client device and one or more remote servers. [Figure 5] 10 is a flowchart illustrating an example of client-side transaction validation logic. [Figure 6] 10 is a flowchart illustrating an example of server-side transaction validation logic. [Figure 7] 1 illustrates an exemplary computing system suitable for use with the exemplary embodiments. [Figure 8] 1 illustrates an exemplary network environment suitable for use with the exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0007] Exemplary embodiments provide techniques for increasing contactless card security while allowing transactions to be performed in a more efficient and user-friendly manner. These embodiments can be used to ensure the card is physically present with the cardholder (which may prevent transactions if the card is stolen for fraudulent in-person transactions) and to ensure the cardholder authorizes the transaction (which may be used to verify either in-person or remote transactions). Furthermore, the process of verifying a transaction involves interaction with a physical token on the card. Because of this interaction, the card must be used to authorize both in-person and remote transactions, and unauthorized transactions may be quickly identified and rejected.

[0008] More specifically, when a user wants to access their account (e.g., on a mobile device), the system requests the cardholder's authorization. The cardholder is asked to sign in to an application running on the mobile device and scan a physical token associated with the card (e.g., a contactless chip capable of wireless communication with the mobile device, such as NFC, Bluetooth, or WiFi, or wired communication, such as via a USB connection). These steps verify that the card is in the cardholder's physical possession. In theory, only the cardholder should be able to sign in to the mobile application, and if the card is scanned by a local NFC reader, it may be confirmed that the cardholder owns the card.

[0009] Each time the card is used, a counter value stored on the physical token may be incremented and sent to a remote server for validation. As part of the scanning process to validate transactions, the counter present on the card may be checked against a remote copy stored on the server. If the counter value read from the card is not the value expected by the server, this may indicate that the card or the owner's account has been used for an unauthorized transaction (indicating that the card was used and the transaction was not recorded because the counter value on the card was not the value expected by the server, or that an attacker is attempting to replay a transaction and replay a previous session that was captured).

[0010] In many cases, the card's counter value may not perfectly match the counter value stored on the server. For example, in the case of a partial read (which may occur if a user places the card near a phone without actually intending to read the value of the physical token), the token's counter may be updated locally, but the remote server may not be updated with an incremented counter value. The degree to which the counter values ​​must match may depend on the risk level of the transaction and / or the current risk profile of the environment (e.g., whether the banking institution is currently under attack). Thus, for low-risk transactions, the card's counter value must match the server's counter value within a certain predetermined range (which allows the system to account for accidental reads of the card). For high-risk transactions, the counter value must match exactly or within a narrower predetermined range. The range may be dynamically determined based on what is known about the user's regular interactions with the card (e.g., if a user has been susceptible to accidental reads of their token in the past, the range may be set higher compared to users whose cards are typically less susceptible to such reads). If the system determines that a mismatch exists, the first action may be to request that the user re-verify the card with an application on the mobile device. In this case, the counter value for this additional authentication must exceed the value included in the suspicious authentication request. If the system still cannot verify the counter value, or for particularly high-risk requests, further verification may be required (e.g., the application may request that the user provide biometric verification, a photo of the user, or a scan of the user's identification. Alternatively, the user may be asked to be physically present at a location such as a bank for in-person verification). These actions allow the verification process to be adapted to the risk profile.

[0011] Similarly, the risk profile may be modified based on information gathered during the verification process. For example, if a transaction was originally flagged as low risk, but a counter value read during the process indicates that fraudulent activity may have occurred, the risk associated with the transaction may be increased. In other examples, if verification of the counter value triggers a reverification process, the risk level associated with this user and / or transaction may be increased.

[0012] Furthermore, these two options (adjusting authentication strength based on risk profile and adjusting risk profile based on authentication results) may be combined and used side by side.

[0013] The following description of the embodiments provides non-limiting representative examples that refer to numerals to particularly explain the features and teachings of different aspects of the present invention. It should be recognized from the description of the embodiments that the described embodiments can be implemented separately or in combination with other embodiments. The description of the embodiments is not specifically exhaustive, but should facilitate understanding of the present invention to the extent that other implementations within the knowledge of a person skilled in the art who reads the description of the embodiments will be understood to be consistent with the application of the present invention.

[0014] 1A illustrates a data transmission environment 100 according to an exemplary embodiment. As described further below, the system 100 may include a contactless card including a physical token 106, a client device 104, a network 114, and several servers 116, 128. While FIG. 1A illustrates a particular configuration of components, those skilled in the art will understand that other configurations including more or fewer components, or other configurations of components, may be used.

[0015] The environment 100 may include one or more contactless cards, which are described further below with reference to FIG. 1B. In some examples, the contactless cards may be in wireless communication, e.g., NFC communication, with the client device 104. The contactless cards may include a physical token 106, such as a contactless chip (see FIG. 1C). The physical token 106 may maintain a copy of the counter value 108, described above, which may be incremented each time the physical token is read by a reader (e.g., NFC reader 110).

[0016] The environment 100 may include a client device 104, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, for example, a computing device or a communication device, including, for example, but not limited to, a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an internet browser, or other device. The client device 104 may also be a mobile device, for example, a mobile device may include an Apple® iPhone®, an iPod®, an iPad®, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® mobile operating system, and / or any other smartphone or similar wearable mobile device.

[0017] The client device 104 and / or the contactless card including the physical token 106 may be associated with a user 102, who may be the owner of the contactless card. The user 102 may define credentials for accessing mobile applications on the client device 104, which may be applications associated with the service provider of the contactless card.

[0018] The client device 104 may include a near field communication reader 110 suitable for communicating with the physical token 106. For example, the NFC reader 110 may be used to read the counter value 108 from the physical token 106.

[0019] In various examples consistent with this disclosure, client device 104 of environment 100 may execute one or more applications, such as software applications. The software applications may enable network communication with one or more components of environment 100 and may transmit and / or receive data. Among other computer-executable logic, client device 104 may include client-side validation logic 112 (such as the logic shown in more detail in connection with FIG. 5).

[0020] The client device 104 may communicate with one or more servers 116, 128 via one or more networks 114 and may operate as a respective front-end to back-end pair with the transaction validation server 116. The client device 104 may send one or more requests to the server 116, for example, from a mobile device application executing on the client device 104. The one or more requests may be associated with retrieving data from the server 116. The server 116 may receive one or more requests from the client device 104. Based on the one or more requests from the client device 104, the server 116 may be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, the server 116 may be configured to transmit the received data to the client device 104, the received data responding to the one or more requests.

[0021] The environment 100 may include one or more servers 116, 128. In some examples, the servers 116, 128 may include one or more processors coupled to memory. The servers 116, 128 may be configured as a central system, server, or platform for controlling and retrieving various data at different times to perform multiple workflow actions. The servers 116, 128 may be configured to connect to one or more databases. The client device 104 may be connected to at least one server 116, 128.

[0022] In one embodiment, the third-party server 128 may require that the transaction be verified. For example, the third-party server 128 may be a server associated with a vendor selling a product or service for which the purchase request is submitted in the name of the user 102. The third-party server 128 may require that the purchase be verified with a service provider.

[0023] To that end, the third-party server 128 may communicate over the network 114 with a transaction validation server 116 affiliated with the service provider. To validate the transaction, the server 116 may execute server-side validation logic 118 (such as the logic shown in FIG. 6 ). The logic 118 may maintain a counter window 120 that defines a range of acceptable counter values ​​(which accounts for accidental readings and other unintended increments of the counter value 108, as described above). The counter window 120 may include several different ranges associated with different risk levels, such as a relatively wide range for low-risk transactions and a relatively narrow range for high-risk transactions (which may require an exact match).

[0024] The counter value 126 may be stored in a user database 122 and indexed into a record 124 associated with the physical token 106. The logic 118 may apply a counter window 120 when evaluating the counter value 126 stored in the user database 122. For example, upon receiving a new counter value 108, the logic 118 may compare the new counter value 108 to the stored counter value 126 to see if the new value 108 exceeds the stored value 126. If so, the logic 118 may determine whether the new value 108 exceeds the stored value 126 by more than a maximum window value (e.g., the sum of the stored value 126 and the window 120). If the new value is less than the combination of the stored value 126 and the window 120, the new value 108 may be determined to be acceptable. If not, the new value 108 may be rejected, and further action may be taken (as described herein). The user database 122 does not necessarily have to be a database, but can be any data structure suitable for storing counter values ​​126 associated with the physical tokens 106 of the users 102 .

[0025] FIG. 1B illustrates one or more contactless cards 130, which may comprise payment cards such as credit cards, debit cards, or gift cards issued by a service provider 132 displayed on the front or back of the card 130. In some examples, the contactless card 130 may comprise, but is not limited to, an identification card unrelated to a payment card. In some examples, the payment card may comprise a dual-interface contactless payment card. The contactless card 130 may comprise a substrate 134, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 130 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it should be understood that contactless cards 130 according to the present disclosure may have different characteristics, and the present disclosure does not require contactless cards to be implemented as payment cards.

[0026] The contactless card 130 may also include identification information 136 displayed on the front and / or back of the card, and a contact pad 138 representing a physical token. The contact pad 138 may be configured to establish contact with a user device or other communication device, such as a smartphone, laptop, desktop, or tablet computer. The contactless card 130 may also include processing circuitry, an antenna, and other components not shown in FIG. 1C . These components may be located behind the contact pad 138 or elsewhere on the substrate 134. The contactless card 130 may also include a magnetic strip or tape (not shown in FIG. 1B ) that may be located on the back of the card.

[0027] 1C, the contact pad 138 of FIG. 1B may include processing circuitry 140 for storing and processing information, including a microprocessor 142 and memory 144. It is understood that processing circuitry 140 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, as needed to perform the functions described herein.

[0028] The memory 144 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 130 may include one or more of these memories. Read-only memory may be read-only or one-time programmable at the factory. One-time programming allows it to be written once and read many times. Write-once read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritten, but it may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. It may be read many times.

[0029] The memory 144 may be configured to store one or more applets 146, one or more counters 108, and a customer identifier 148. The one or more applets 146 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 146 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device with limited memory. The one or more counters 108 may comprise a numeric counter sufficient to store an integer. The customer identifier 148 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 130, which identifier may distinguish the contactless card user from other contactless card users. In some examples, the customer identifier 148 may identify both the customer and the account assigned to the customer, and further identify the contactless card associated with the customer's account.

[0030] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto, and it will be understood that these elements may be implemented external to, or entirely separate from, the pads 138, or as additional elements in addition to the processor 142 and memory 144 elements located within the contact pads 138.

[0031] In some examples, contactless card 130 may include one or more antennas 150. One or more antennas 150 may be disposed within contactless card 130 and around processing circuit 140 on contact pads 138. For example, one or more antennas 150 may be integrated with processing circuit 140, or one or more antennas 150 may be used with an external booster coil. As another example, one or more antennas 150 may be external to contact pads 138 and processing circuit 142.

[0032] In one embodiment, the coil of the contactless card 130 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 130 by disconnecting the power or amplitude modulation. The contactless card 130 may infer data transmitted from the terminal using gaps in the contactless card's power connection, which may be maintained functionally through one or more capacitors. The contactless card 130 may return communication by switching the load on the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil through interference.

[0033] As described above, contactless card 130 may be built on a software platform operable on a memory-limited smart card or other device, such as a Java Card, and one or more applications or applets may be securely executed. The applets may be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applets may be configured to respond to one or more requests, such as Near Field Wireless Data Exchange (NDEF) requests, from a reader, such as a mobile NFC reader, and generate an NDEF message comprising the cryptographically secure OTP encoded as an NDEF text tag.

[0034] As described above, an exemplary transaction may verify a requested transaction to an account associated with a contactless card via logic 112 executing on client device 104. Figures 2A-2B show exemplary interfaces that may be presented on client device 104 in response to the logic.

[0035] Before displaying the interface, the user of the client 104 may be notified that the transaction requires verification. For example, the user may receive an SMS message from the service provider, a notification via the service provider's application, a phone call, or an email.

[0036] Upon receiving the notification, the user may log in to the service provider's application. For example, the user may enter a username and password to verify the user's identity. In other embodiments, the user may be verified in other ways, such as via biometric data. In some embodiments, the login may utilize two-factor authentication (2FA).

[0037] When a user logs into the application, an interface such as interface 200 shown in Figure 2A may be displayed. The interface may display a message 202 indicating that a suspicious transaction has been received and requires verification. Message 202 may include details of the transaction, such as the value of the transaction, the name of the vendor attempting to verify the transaction, etc.

[0038] The interface 200 may include an interactive element 204 that allows a user to flag a transaction as fraudulent if the user did not authorize the transaction. Selecting the interactive element 204 may cause the application to send a fraud alert message to the transaction validation server indicating that the transaction in question was not authorized.

[0039] Message 202 may also include instructions for verifying the transaction if the user approves the transaction. In one embodiment, verifying the transaction may include tapping card 130 against a reader on the back of client device 104, as shown in FIG. 2B. The reader may read the counter value from the physical token on card 130 and generate message 300 (see FIG. 3) that includes counter value 304 and authentication ciphertext 306. Message 300 may be encrypted.

[0040] The counter value 304 may correspond to the most recently read counter value from the card, and the authentication cryptogram 306 may be generated based on an encryption key stored in the physical token 138 and may be used to authenticate the card with the transaction validation server and ensure that the message 300 has not been tampered with or corrupted.

[0041] The message 300 may also include a token identifier 302 that may identify the card 130 and / or the user associated with the card. For example, the token identifier 302 may correspond to the unique customer identifier 148 stored on the physical token 138.

[0042] Upon receiving message 300, the transaction verification server may decrypt message 300, verify the card and message based on cryptogram 306, match the message to a user account based on token identifier 302, and retrieve the user record 124 (see FIG. 1A) from the transaction verification server corresponding to the user account. The transaction verification server may then compare counter value 304 with corresponding counter value 126 stored in user database 122 to verify that the number of swipes or transactions on the card matches the expected counter value stored on the server. This may verify that the user possesses the card (i.e., that message 300 is not forged) and that the number of transactions performed by the user matches the service provider's expectations. If the counter values ​​are out of sync, this may indicate that an unauthorized transaction has been attempted, and the current transaction may be denied (or additional verification action may be required).

[0043] Those skilled in the art will appreciate that message 300 is depicted in a simplified format. In some embodiments, other components may be present in the message, or the depicted components may be combined or modified.

[0044] 2C is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. The system may include a contactless card 130 and a client device 104 that may include an application (which may include logic 112) and a processor.

[0045] At 202, the application communicates with the contactless card 130 (e.g., after being brought into proximity with the contactless card 130). Communication between the application and the contactless card 130 may involve the contactless card 130 being sufficiently close to a card reader (not shown) of the client device 104 to enable NFC data transfer between the application and the contactless card 130.

[0046] In step 204, after communication is established between the client device 104 and the contactless card 130, the contactless card 130 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 130 is read by an application (e.g., on the client 104). In particular, this may occur upon a read, such as an NFC read, of a Near Field Communication (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader, such as an application, may send a message, such as an applet select message, using the applet ID of the NDEF generation applet. Once the selection is confirmed, a sequence of select file messages followed by a read file message may be sent. For example, the sequence may include "select feature file," "read feature file," and "select NDEF file." At this point, a counter value maintained by the contactless card 130 may be updated or incremented, followed by "read NDEF file." At this point, a message may be generated, which may include a header and a shared secret. A session key may then be generated. A MAC ciphertext may be created from the message, which may include a header and a shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with a session key. The ciphertext and header may then be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

[0047] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples, the MAC cryptogram may be included with a uniform resource indicator (eg, as a formatted string).

[0048] In some examples, the application may be configured to send a request to contactless card 130, the request including instructions to generate a MAC cryptogram.

[0049] At 206, the contactless card 130, in response to the instruction from the client device 104, transmits the MAC cryptogram to the application.

[0050] At 208, the application communicates the MAC ciphertext to the processor.

[0051] At 210, the processor verifies the MAC ciphertext. For example, it may decrypt the MAC ciphertext. In some examples, the verification of the MAC ciphertext may be performed by a device other than the client device 104, such as a server connected to the client device 104. For example, the processor may output the MAC ciphertext for transmission to the server, which may verify the MAC ciphertext.

[0052] FIG. 4 is a timing diagram illustrating an example of data exchange between an operating system on a client device, an application on the client device, a transaction validation server, and a third-party server processing a transaction.

[0053] At 402, a third-party server (e.g., a server associated with a vendor for which a credit transaction is requested) may submit a transaction request to a transaction validation server associated with a service provider. The transaction request may be generated in response to scanning a credit card, entering a credit card number into a vendor's payment system, an online transaction with a vendor, etc. The service provider may be identified as part of the process to receive information related to the card.

[0054] The transaction request may be sent to a transaction validation server, which may apply a risk analysis 404 to the requested transaction. The risk analysis 404 may identify a risk level associated with the transaction. For example, the risk analysis 404 may consider the purchase amount, the purchase location, the user's previous purchasing history, the overall risk environment (including factors such as whether the institution, such as the bank that issued the contactless card 130, is currently under attack or whether other institutions have reported a recent increase in fraud), etc. in determining whether the transaction is typical of the user's activity (and therefore low risk) or atypical (and therefore high risk).

[0055] Based on the risk analysis 404, an initial risk score may be assigned to the transaction. A set of risk tiers may be defined, with each risk tier associated with a risk score range and a required verification action. For example, for a low risk score, the low risk tier may not require any verification action. For a medium risk score, the medium risk tier may require verification by the user by scanning a physical token with a mobile client (in combination with logging in to an application on the mobile client). For a high risk score, the high risk tier may require additional verification actions in addition to those of the medium tier. If the risk score is very high, the transaction may be rejected entirely.

[0056] The initial risk score may be compared to a range of risk scores for the risk tier and assigned to a particular risk tier. Based on the validation actions associated with the risk tier, the associated validation actions may be retrieved and executed.

[0057] The example in Figure 4 illustrates a situation that occurs when the initial risk score is associated with a medium risk (i.e., the physical token needs to be scanned and verified). Thus, at 406, a verification request is generated by the server and sent to the client application. The verification request may generate a notification informing the user that a recent transaction needs to be verified.

[0058] In response to the notification, the user may log in to the client application using any suitable means (e.g., username / password combination, biometric authentication, etc.). The user may then be presented with an interface (such as that shown in FIG. 2A) and scan the physical token on the card. Accordingly, at 408, the client application may request access to a physical token reader (e.g., an NFC reader) from the client device's operating system. At 410, the client OS may receive a response (e.g., including a counter value) from the reader and forward the response to the client application. Actions 408 and 410 may include actions similar to those described above in connection with FIG. 2C.

[0059] At 412, the client application may generate a validation response (eg, message 300) and send the response to the transaction validation server.

[0060] At 414, the transaction validation server may perform a validation analysis, which may include verifying the cryptogram included in the validation response 412 and comparing the counter value received from the client with a corresponding counter value stored on the server.

[0061] As described above, differences between the counter value stored on the physical token and the counter value stored on the transaction validation server may indicate the presence of a fraudulent transaction. However, for legitimate reasons (e.g., a partial read not sent to the server, an initial read occurring during OS startup, etc.), the counter value stored on the physical token may become out of sync with the counter value stored on the server. A risk tier associated with the risk analysis may define an acceptable range of variance between the counter value received from the client and the counter value stored on the server. For example, a relatively low risk tier may provide a relatively wide range of variance, while a relatively high risk tier may provide a relatively narrow range (or no range, requiring an exact match).

[0062] If the counter value is within the acceptable range, processing may proceed directly to 426 where approval of the transaction may be sent to the third party server.

[0063] In addition to the range of acceptable counter values, the risk tiers may define various escalation ranges. For example, if the counter value is not within the acceptable range but is within a secondary range, additional validation actions may be required to validate the transaction. Alternatively, the initial risk score may be re-evaluated to account for discrepancies between the counter value from the client and the counter value stored on the server, and the transaction may be elevated to a higher risk tier based on the newly calculated risk score.

[0064] If the counter value is outside the secondary range, the transaction may be rejected at 426. If further validation action is required because the counter value is outside the acceptable range, the dashed actions shown in Figure 4 may be performed.

[0065] To this end, an escalated verification request may be sent to the client application at 416. The escalated verification request may include a requested verification action to be performed based on an escalated risk hierarchy or an escalated risk action required by the verification analysis. For example, the escalated verification action may include answering a security question, providing biometrics, taking a photo of the user's identity, or presenting themselves at a defined location.

[0066] In this example, the escalated verification request 416 requests the user to take a photograph of an identification, such as a driver's license. Thus, at 418, the application may request access to the device camera from the client operating system. The photograph may be captured and sent to the client application at 420. Based on the captured photograph, an escalated verification response may be generated at 422 and sent to the transaction verification server.

[0067] At 424, the server may perform an escalated verification analysis on the escalated verification response. For example, the server may compare a photo of the user in the identity to a photo stored on the server, compare a signature of the user on the identity to a stored signature, or take other appropriate action based on the escalated verification response (e.g., compare the biometric authentication to a biometric authentication stored on the server, receive an indication that the client device confirmed the biometric authentication, etc.).

[0068] Optionally, at 428, the server may update the current risk score based on information determined during the verification process. For example, if the counter value is such that additional escalated verification is not required, the server may update the risk score to indicate a decreased risk. However, if additional escalated verification is required and the additional verification is successful, the risk score may be updated to maintain the current risk level. If authentication fails, the risk level may be updated to indicate a higher risk level going forward.

[0069] The above actions may be performed by the client-side validation logic 500 (FIG. 5) in conjunction with the server-side validation logic 600 (FIG. 6).

[0070] The client-side verification logic 500 may include logic for authenticating a user to a client-side service provider application at block 502. For example, the logic may include instructions for verifying a username and password combination, verifying biometric login information, etc.

[0071] At block 504, a verification request may be received from a transaction verification server. The verification request may specify details of the transaction being verified and / or required verification actions (such as scanning a card's physical token).

[0072] Blocks 502 and 504 may be performed in reverse to receive a verification request prior to authentication to the application.

[0073] In response to the verification request, the client application may invoke a short-range (e.g., NFC) reader on the client device at block 506. At block 508, the reader may be used to exchange or read information with the physical token, including a counter value cryptographically encoded on the token using one or more security keys.

[0074] At block 510, the device may generate a validation response, which may include the cryptographically encoded counter value read from the token at 508. At block 512, the validation response may be sent to the transaction validation server.

[0075] If the server determines that escalated verification is required, the client may receive the escalated verification request and perform the specified escalated verification action (e.g., capture a photograph of the user's identity) at block 514. The client may respond to the escalated verification request using information captured in response to the escalated verification action.

[0076] FIG. 6 shows the corresponding logic 600 executed by the validation server.

[0077] At block 502, the verification server may receive a transaction request from a vendor server. The transaction request may specify the identity of the vendor, the amount of the transaction, and other relevant details that may be used by the risk analysis performed at block 604.

[0078] Based on the risk analysis, an initial risk score may be calculated and associated verification actions may be obtained. In some cases, verification actions may not be necessary. The system may determine whether this is the case at block 606, and if verification is not necessary (e.g., because the risk score is below a predefined lower threshold), processing may proceed to block 608, where the transaction may be approved. Accordingly, an approval message may be generated and sent to the vendor server.

[0079] If verification is required, the server may send a verification request to the client device associated with the user account assigned to the transaction (e.g., based on information obtained from user database 122 of FIG. 1A) at block 610. The server may receive a verification response from the client at block 612 having the requested information.

[0080] The validation response may be processed to, for example, authenticate the cryptogram of the validation response and obtain a counter value. At block 614, the server may identify a risk tier determined by the risk analysis performed at block 604.

[0081] In this example, two risk tiers (high and low) are defined. Based on the risk tier, a range of counter values ​​may be defined (e.g., a narrow window for the high risk tier and a wide window for the low risk tier). In some cases, the range of counter values ​​may be a predetermined range associated with a risk score. Alternatively, the range of counter values ​​may be dynamically determined based on the risk score or risk factors (such as the current risk level of the environment). There may be multiple different risk tiers, each with its own window size.

[0082] If the received counter value is within the range specified for the risk tier ("Yes" at block 618 or 616), processing continues to block 608 and the transaction may be approved.

[0083] On the other hand, if the counter value is not within the range specified for the risk tier ("No" at block 616 or 618), processing may proceed to block 620. Optionally, escalated validation may be performed at this block. As part of the escalated validation procedure, an updated risk score may be calculated and the risk score may be matched against the new risk tier. Alternatively, escalated validation actions defined for the current risk tier may be performed.

[0084] If the escalated verification is successful, processing proceeds to block 608, where the transaction may be approved. If the escalated verification is not successful, or if the escalated verification is not performed at this stage, processing proceeds to block 622, where the transaction may be denied. Alternatively, if the escalated verification is not successful, processing returns to block 620, where a further updated risk score may be calculated. This process may be repeated until a predetermined maximum number of iterations has occurred, until the risk score exceeds a predetermined maximum threshold, or until a predefined stopping condition is met.

[0085] At any point during this process (e.g., during the approval or denial at blocks 608 and / or 622), data from the authentication process may be fed back into the system for use as part of the risk calculation process. Thus, the risk calculation may be updated based on the authentication / verification procedure, and vice versa. This may enable the system to create a feedback loop in which the authentication process influences the risk assessment, and the risk assessment influences the authentication process.

[0086] The above methods may be embodied as instructions on a computer-readable medium or as part of a computing architecture. Figure 7 shows an embodiment of an exemplary computing architecture 700 suitable for implementing various embodiments as described above. In one embodiment, computing architecture 700 may comprise or be implemented as part of an electronic device such as a computer 701. In this context, the embodiments are not limited.

[0087] As used in this application, the terms “system” and “component” are intended to refer to any computer-related entity: hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other and coordinate operations by various types of communication media. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections, examples of which include parallel interfaces, serial interfaces, and bus interfaces.

[0088] Computing architecture 700 may include various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by computing architecture 700.

[0089] 7, computing architecture 700 includes a processing unit 702, a system memory 704, and a system bus 706. Processing unit 702 may be any of a variety of commercially available processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core® Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processing unit 702.

[0090] The system bus 706 provides an interface to system components, including but not limited to, system memory 704, to the processing unit 702. The system bus 706 may be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may connect to the system bus 706 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0091] Computing architecture 700 may comprise or be embodied in a variety of articles of manufacture. The article of manufacture may comprise a computer-readable storage medium that stores logic. Examples of computer-readable storage media include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions embodied using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

[0092] The system memory 704 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 7, the system memory 704 may include non-volatile memory 708 and / or volatile memory 710. The non-volatile memory 708 may store a basic input / output system (BIOS).

[0093] Computing architecture 700 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 712, a magnetic floppy disk drive (FDD) 714 that reads from or writes to a removable magnetic disk 716, and an optical disk drive 718 that reads from or writes to a removable optical disk 720 (e.g., a CD-ROM or DVD). HDD 712, FDD 714, and optical disk drive 720 may be connected to system bus 706 by an HDD interface 722, an FDD interface 724, and an optical drive interface 726, respectively. HDD interface 722 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 694 interface technologies.

[0094] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 708, 712, including an operating system 728, one or more application programs 730, other program modules 732, and program data 734. In one embodiment, the one or more application programs 730, other program modules 732, and program data 734 may include, for example, various applications and / or components of messaging system 500.

[0095] A user may enter commands and information into the computer 701 through one or more wired / wireless input devices, for example, a keyboard 736 and a pointing device such as a mouse 738. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, grab, graphics tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processing unit 702 through an input device interface 740 coupled to the system bus 706, but may be connected by other interfaces, such as a parallel port, an IEEE 694 serial port, a game port, a USB port, an IR interface, etc.

[0096] A monitor 742 or other type of display device is also connected to the system bus 706 via an interface, such as a video adapter 744. The monitor 742 can be internal or external to the computer 701. In addition to the monitor 742, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0097] The computer 701 may operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 744. The remote computer 744 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node and typically includes many or all of the elements described relative to the computer 701, although for simplicity, only a memory / storage device 746 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 748 and / or larger networks, e.g., a wide area network (WAN) 750. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks, such as intranets. All of these may be connected to a global communications network, e.g., the Internet.

[0098] When used in a LAN networking environment, the computer 701 is connected to the LAN 748 through a wired and / or wireless communication network interface or adapter 752. The adapter 752 may facilitate wired and / or wireless communication to the LAN 748, which may include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 752.

[0099] When used in a WAN networking environment, the computer 701 may include a modem 754 or have other means for establishing communications over the WAN 750, such as connecting to a communications server on the WAN 750 or via the Internet. The modem 754 may be internal or external, a wired and / or wireless device, and connects to the system bus 706 via the input device interface 740. In a networked environment, program modules depicted relative to the computer 701, or portions thereof, may be stored in the remote memory / storage device 746. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0100] The computer 701 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.13 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies known as IEEE 802.13x (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, or to wired networks (using IEEE 802.3-related media and functions).

[0101] 8 is a block diagram illustrating an exemplary communications architecture 800 suitable for implementing the various embodiments described above. Communications architecture 800 includes various common communications elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to implementation by communications architecture 800.

[0102] 8, communication architecture 800 includes one or more client(s) 802 and server(s) 804. Client(s) 802 may implement client device 510. Server(s) 804 may implement server device 526. Client(s) 802 and server(s) 804 are operatively connected to one or more respective client data store(s) 806 and server data store(s) 808, which may be employed to store information local to the respective client(s) 802 and server(s) 804, such as cookie(s) and / or associated contextual information.

[0103] The client 802 and the server 804 may communicate information with each other using a communication framework 810. The communication framework 810 may implement well-known communication technologies and protocols. The communication framework 810 may be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., the public switched telephone network), or a combination of packet-switched and circuit-switched networks (using appropriate gateways and translators).

[0104] The communications framework 810 may implement various network interfaces configured to accept, communicate, and connect to communications networks. A network interface may be considered a specialized form of input / output interface. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000BaseT, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.8a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. Additionally, multiple network interfaces may be used to interface with various communications network types. For example, multiple network interfaces may be used to enable communications over broadcast, multicast, and unicast networks. When processing requirements dictate speed and capacity, a distributed network controller architecture may similarly be used to pool, load balance, and otherwise increase the communications bandwidth needed by the clients 802 and servers 804. The communications network may be any one and combination of wired and / or wireless networks, including, but not limited to, direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operational missions as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communications networks.

[0105] The components and functions of the above-described devices may be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, device functions may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing, where appropriate. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0106] It should be understood that the exemplary devices shown in the block diagrams above may represent one example illustrating the functionality of many potential implementations. Thus, the division, omission, or inclusion of block functions shown in the accompanying figures does not necessarily mean that the hardware components, circuits, software, and / or elements for implementing those functions are necessarily divided, omitted, or included in the embodiments.

[0107] At least one computer-readable storage medium may contain instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein.

[0108] Some embodiments may be described using the phrase "one embodiment" or "an embodiment," along with its derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment. Furthermore, unless otherwise specified, it is recognized that the above-described features can be used together in any combination. Thus, any features described individually may be used in combination with each other, unless it is noted that these features are not compatible with each other.

[0109] Generally referring to the notation and terminology used herein, the detailed descriptions herein may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0110] A procedure is here generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0111] Further, the manipulations performed are often referred to in terms, such as adding or comparing, that are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein that form part of one or more embodiments. Rather, the operations are machine operations. Useful machines for performing the operations of various embodiments include general purpose digital computers or similar devices.

[0112] Some embodiments may be described using the terms "coupled" and "connected," along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other.

[0113] Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The procedures presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will be apparent from the description given.

[0114] It is emphasized that the Abstract of the Disclosure is provided to enable the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprising" and "in which" are used as the plain-English equivalents of "comprising" and "wherein," respectively. Additionally, terms such as "first," "second," and "third" are used merely as labels and are not intended to impose numerical requirements on their subject matter.

[0115] What has been described above includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many more combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to: receiving a request from a verification server, the request being associated with a user account associated with the user; performing a first verification action by authenticating the identity of the user at a computing device; performing a second verification action by receiving a scan of the code from the physical token via a short-range communication protocol; generating a verification response package based on the first verification action and the second verification action, the verification response package identifying the user and the code obtained from the physical token; sending the response package to the validation server; A medium that allows the execution of the following:

2. The medium of claim 1 , wherein the short-range communication protocol is a Near Field Communication (NFC) protocol.

3. 10. The medium of claim 1, wherein the code is a counter stored in the physical token that is incremented each time the code is read from the physical token.

4. The medium of claim 1 , wherein the physical token is computing hardware physically embedded in a credit card.

5. The medium of claim 1 , wherein authenticating the identity of the user includes logging the user into the user account of an application running on the computing device.

6. The medium is receiving an escalated verification request in response to transmitting the response package; receiving a photograph from a camera of the computing device; generating a response to the escalated verification request, the response including the photograph; and The medium of claim 1 further storing instructions for:

7. The medium of claim 6 , wherein the escalated verification request is a request for a photograph of an identification associated with the user.

8. receiving a request confirming a user's intent to perform a transaction associated with the service; receiving a cumulative value from a physical token associated with the user; accessing a log that maps users of the service to the last known value of their respective physical tokens; obtaining from the log the last known value of the physical token associated with the user; identifying a window of acceptable values ​​around the last known value of the physical token; determining that the accumulated value received from the physical token is within the window of acceptable values; causing the transaction to be executed when the cumulative value is within the window; A method comprising:

9. The method of claim 8 , wherein the physical token is a credit card.

10. The method of claim 8 , wherein the window is a single value.

11. The method of claim 8 , wherein the window is a range of values.

12. 12. The method of claim 11, wherein the range is a dynamic range, the method further comprising modifying the window based on user profile information indicative of an estimated rate at which the cumulative value is unintentionally incremented.

13. The method comprises: The method of claim 8 , further comprising calculating a risk value associated with the transaction.

14. The method of claim 13 , wherein the size of the window varies depending on the risk value.

15. 1. A system comprising: a verification server configured to send a request to authenticate a user associated with the user account; a client device configured to receive information obtained from scanning a code from a physical token; the verification server is further configured to authenticate the information, the authentication including comparing the code received from the physical token with a corresponding code stored on the verification server, the authentication being performed at least in part based on a risk assessment.

16. The apparatus of claim 15 , wherein the authentication includes failing an initial authentication procedure and sending a request for further authentication.

17. The apparatus of claim 16 , wherein the validation server is further configured to determine that further authentications have failed and to increase a level of risk associated with the risk assessment in response to the failure.

18. 17. The apparatus of claim 16, wherein the validation server is further configured to determine that the further authentication is successful and to maintain or reduce a level of risk associated with the risk assessment in response to the success.

19. The apparatus of claim 15 , wherein the authentication includes passing an initial authentication procedure and reducing a level of risk associated with the risk assessment in response to the success.

20. The apparatus of claim 15 , wherein the validation server is further configured to determine to adjust the risk assessment based on information determined during the authentication.

Images