Systems and methods for scalable cryptographic authentication of contactless cards

Information

  • Patent Grant
  • 12335412
  • Patent Number
    12,335,412
  • Date Filed
    Monday, June 21, 2021
    4 years ago
  • Date Issued
    Tuesday, June 17, 2025
    18 days ago
Abstract
Systems and methods for authentication may include an authentication server. The authentication server may include a processor and a memory. The processor may be configured to transmit an authentication request. The processor may be configured to receive a first response that is responsive to the authentication request, the first response comprising a first cryptogram. The processor may be configured to generate a first challenge based on the first response. The processor may be configured to encrypt the first challenge with a symmetric key. The processor may be configured to transmit the first challenge receive a second response that is responsive to the first challenge, the second response comprising a second cryptogram. The processor may be configured to authenticate the second response.
Description
FIELD OF THE DISCLOSURE

The present disclosure relates to systems and methods for scalable cryptographic authentication of contactless cards.


BACKGROUND

Card-based transactions are becoming increasingly common. These transactions often involve the use of a card in communication with a point of sale device, a server, or other device. It is necessary to protect such communications from interception and unauthorized access.


However, transmission of data without encryption or other protection is susceptible to phishing attacks, and replay attacks, and may be subject to other vulnerabilities, resulting in increased security risks and increased risks of account or card misuse. These risks may be further increased through the use of contactless cards, which communicate with other devices wirelessly.


Measures taken to address security risk may consume system resources and hinder operational efficiency. For large numbers of transactions, the consumption of system resources and the hindrance of transaction efficiency can increase, which may result in a failure to perform transactions or unsatisfactory performance.


These and other deficiencies exist. Accordingly, there is a need for systems and methods for authentication that overcome these deficiencies by protecting communications from interception and unauthorized access in a secure and reliable manner.


SUMMARY OF THE DISCLOSURE

Embodiments of the present disclosure provide an authentication server. The authentication server may include a processor and a memory. The processor may be configured to transmit an authentication request. The processor may be configured to receive a first response that is responsive to the authentication request, the first response comprising a first cryptogram. The processor may be configured to generate a first challenge based on the first response. The processor may be configured to encrypt the first challenge with a symmetric key. The processor may be configured to transmit the first challenge receive a second response that is responsive to the first challenge, the second response comprising a second cryptogram. The processor may be configured to authenticate the second response.


Embodiments of the present disclosure provide a method of authentication. The method may include transmitting an authentication request. The method may include receiving a first response that is responsive to the authentication request, the first response comprising a first cryptogram. The method may include generating a first challenge based on the first response. The method may include encrypting the first challenge with a symmetric key. The method may include transmitting the first challenge. The method may include receiving a second response that is responsive to the first challenge, the second response comprising a second cryptogram. The method may include authenticating the second response.


Embodiments of the present disclosure provide a computer readable non-transitory medium comprising computer executable instructions that, when executed on a processor, perform procedures comprising the steps of: transmitting an authentication request; receiving a first response that is responsive to the authentication request, the first response comprising a first cryptogram; generating a first challenge based on the first response; encrypting the first challenge with a symmetric key; transmitting the first challenge; receiving a second response that is responsive to the first challenge, the second response comprising a second cryptogram; and authenticating the second response.





BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings.



FIG. 1 depicts an authentication server according to an exemplary embodiment.



FIG. 2A is an illustration of a contactless card according to an exemplary embodiment.



FIG. 2B is an illustration of a contact pad of a contactless card according to an exemplary embodiment.



FIG. 3 depicts a method of authentication according to an exemplary embodiment.



FIG. 4 depicts a sequence diagram of a process for authentication according to an exemplary embodiment.



FIG. 5 depicts a method of authentication according to an exemplary embodiment.



FIG. 6 depicts a method of authentication according to an exemplary embodiment.





DETAILED DESCRIPTION

The following description of embodiments provides non-limiting representative examples referencing numerals to particularly describe features and teachings of different aspects of the invention. The embodiments described should be recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments should be able to learn and understand the different described aspects of the invention. The description of embodiments should facilitate understanding of the invention to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the invention.


Benefits of the systems and methods disclosed herein include improved authentication by protecting communications from interception and unauthorized access. The systems and methods disclosed herein allow for the avoidance of phishing attacks, preventing replay attacks through encrypted data communications, and the reduction of other security vulnerabilities.


In addition, challenges may be generated and corresponding responses may be transmitted via customized commands to improve authentication. By doing so, security risks can be further mitigated and transaction efficiency can be improved.


These features can be implemented without degrading the user experience by burdening the user with unnecessary security tasks. Further, these features can be performed in a manner that allows for the time-efficient performance of transactions, in order to comply with user expectations and transaction requirements.


Additionally, the systems and methods described herein are scalable, allowing for use with a large number of transactions. By doing so, large numbers of transactions can be performed in a timely and satisfactory manner, while maintaining transaction efficiency and efficient use of system resources.


Accordingly, the systems and methods disclosed herein reduce the risk of fraudulent activity, such as misuse of the card or an account associated with the card, and address authentication implementations that lack scalability, while promoting transaction efficiency and avoiding degradation of the user experience. Unlike conventional systems that rely on using a limited number of random keys and a successful registration, the systems and methods disclosed herein allow for producing and reproducing a significant number, such as in the millions, of keys by using key diversification. Furthermore, card issuance advantageously provides information relevant for identification and authentication.



FIG. 1 illustrates an authentication system 100. The system 100 may comprise a first device 105, a second device 110, a network 115, a server 120, and a database 125. Although FIG. 1 illustrates single instances of components of system 100, system 100 may include any number of components.


System 100 may include a first device 105. The first device 105 may comprise a contactless card, a contact-based card, a network-enabled computer, or other device described herein. As referred to herein, a network-enabled computer may include, but is not limited to a computer device or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a contactless card, a thin client, a fat client, an Internet browser, a kiosk, a tablet, a terminal, or other device. As further explained below in FIGS. 2A-2B, first device 105 may include one or more processors 102, and memory 104. Memory 104 may include one or more applets 106 and one or more counters 108. Each counter 108 may include a counter value. Memory 104 may include the counter value, transmission data, and at least one key.


First device 105 may include a communication interface 107. The communication interface 107 may comprise communication capabilities with physical interfaces and contactless interfaces. For example, the communication interface 107 may be configured to communicate with a physical interface, such as by swiping through a card swipe interface or inserting into a card chip reader found on an automated teller machine (ATM) or other device configured to communicate over a physical interface. In other examples, the communication interface 107 may be configured to establish contactless communication with a card reading device via a short-range wireless communication method, such as NFC, Bluetooth, Wi-Fi, RFID, and other forms of contactless communication. As shown in FIG. 1, the communication interface 107 may be configured to communicate directly with the second device 110, server 120, and/or database 125 via network 115.


First device 105 may be in data communication with any number of components of system 100. For example, first device 105 may transmit data via network 115 to second device 110, and/or server 120. First device 105 may transmit data via network 115 to database 125. In some examples, first device 105 may be configured to transmit data via network 115 after entry into one or more communication fields of any device. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.


System 100 may include a second device 110. The second device 110 may include one or more processors 112, and memory 114. Memory 114 may include one or more applications, including but not limited to application 116. Second device 110 may be in data communication with any number of components of system 100. For example, second device 110 may transmit data via network 115 to server 120. Second device 110 may transmit data via network 115 to database 125. Without limitation, second device 110 may be a network-enabled computer. Second device 110 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.


The second device 110 may include processing circuitry and may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofing hardware, as necessary to perform the functions described herein. The second device 110 may further include a display and input devices. The display may be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device for entering information into the user's device that is available and supported by the user's device, such as a touch-screen, keyboard, mouse, cursor-control device, touch-screen, microphone, digital camera, video recorder or camcorder. These devices may be used to enter information and interact with the software and other devices described herein.


System 100 may include a network 115. In some examples, network 115 may be one or more of a wireless network, a wired network or any combination of wireless network and wired network, and may be configured to connect to any one of components of system 100. For example, first device 105 may be configured to connect to server 120 via network 115. In some examples, network 115 may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and/or the like.


In addition, network 115 may include, without limitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. In addition, network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 115 may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate to or from other protocols to one or more protocols of network devices. Although network 115 is depicted as a single network, it should be appreciated that according to one or more examples, network 115 may comprise a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, such as credit card association networks, and home networks.


System 100 may include one or more servers 120. In some examples, server 120 may include one or more processors 122 coupled to memory 124. Server 120 may be configured as a central system, server or platform to control and call various data at different times to execute a plurality of workflow actions. Server 120 may be configured to connect to first device 105. Server 120 may be in data communication with the applet 106 and/or application 116. For example, a server 120 may be in data communication with applet 106 via one or more networks 115. First device 105 may be in communication with one or more servers 120 via one or more networks 115, and may operate as a respective front-end to back-end pair with server 120. First device 105 may transmit, for example from applet 106 executing thereon, one or more requests to server 120. The one or more requests may be associated with retrieving data from server 120. Server 120 may receive the one or more requests from first device 105. Based on the one or more requests from applet 106, server 120 may be configured to retrieve the requested data. Server 120 may be configured to transmit the received data to applet 106, the received data being responsive to one or more requests.


In some examples, server 120 can be a dedicated server computer, such as bladed servers, or can be personal computers, laptop computers, notebook computers, palm top computers, network computers, mobile devices, wearable devices, or any processor-controlled device capable of supporting the system 100. While FIG. 1 illustrates a single server 120, it is understood that other embodiments can use multiple servers or multiple computer systems as necessary or desired to support the users and can also use back-up or redundant servers to prevent network downtime in the event of a failure of a particular server.


Server 120 may include an application comprising instructions for execution thereon. For example, the application may comprise instructions for execution on the server 120. The application of the server 120 may be in communication with any components of system 100. For example, server 120 may execute one or more applications that enable, for example, network and/or data communications with one or more components of system 100 and transmit and/or receive data. Without limitation, server 120 may be a network-enabled computer. Server 120 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.


The server 120 may include processing circuitry and may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofing hardware, as necessary to perform the functions described herein. The server 120 may further include a display and input devices. The display may be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device for entering information into the user's device that is available and supported by the user's device, such as a touch-screen, keyboard, mouse, cursor-control device, touch-screen, microphone, digital camera, video recorder or camcorder. These devices may be used to enter information and interact with the software and other devices described herein.


System 100 may include one or more databases 125. The database 125 may comprise a relational database, a non-relational database, or other database implementations, and any combination thereof, including a plurality of relational databases and non-relational databases. In some examples, the database 125 may comprise a desktop database, a mobile database, or an in-memory database. Further, the database 125 may be hosted internally by any component of system 100, such as the first device 105 or server 120, or the database 125 may be hosted externally to any component of the system 100, such as the first device 105 or server 120, by a cloud-based platform, or in any storage device that is in data communication with the first device 105 and server 120. In some examples, database 125 may be in data communication with any number of components of system 100. For example, server 120 may be configured to retrieve the requested data from the database 125 that is transmitted by applet 106. Server 120 may be configured to transmit the received data from database 125 to applet 106 via network 115, the received data being responsive to the transmitted one or more requests. In other examples, applet 106 may be configured to transmit one or more requests for the requested data from database 125 via network 115.


In some examples, exemplary procedures in accordance with the present disclosure described herein can be performed by a processing arrangement and/or a computing arrangement (e.g., computer hardware arrangement). Such processing/computing arrangement can be, for example entirely or a part of, or include, but not limited to, a computer/processor that can include, for example one or more microprocessors, and use instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device). For example, a computer-accessible medium can be part of the memory of the first device 105, second device 110, server 120, and/or database 125, or other computer hardware arrangement.


In some examples, a computer-accessible medium (e.g., as described herein above, a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a collection thereof) can be provided (e.g., in communication with the processing arrangement). The computer-accessible medium can contain executable instructions thereon. In addition or alternatively, a storage arrangement can be provided separately from the computer-accessible medium, which can provide the instructions to the processing arrangement so as to configure the processing arrangement to execute certain exemplary procedures, processes, and methods, as described herein above, for example.


The server 120 may be configured to transmit a first request. For example, the first request may comprise an authentication request. The application 116 of the client device 110 may be configured to receive the first request. The application 116 of the client device 110 may be configured to conduct one or more reads of the first device 105, such as the card. For example, the application 116 may be configured to conduct a read, such as a near field communication read, of a tag of the card 105.


The one or more processors 102 of card 105 may be configured to create a cryptogram using at least one key and a counter value. The cryptogram may include the counter value and the transmission data. The one or more processors 102 of card 105 may be configured to transmit the first cryptogram. The one or more processors 102 of card 105 may be configured to transmit, after entry into one or more communication fields of any device, data responsive to the read, such as a first read. For example, the one or more processors 102 of card 105 may be configured to transmit, after a first entry into a first communication field of the device, the first cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof. The first cryptogram may be received, upon request, via a near field communication data exchange format (NDEF) read. The one or more processors 102 of card 105 may be configured to transmit the first cryptogram. The application 116 of the client device 110 may be configured to receive the first cryptogram and a public key from a response transmitted by the one or more processors 102 of the card 105. In some examples, the one or more processors 102 of the card 105 may be configured to generate and transmit, to the application 116 of the client device 110, the first cryptogram using a shared secret. In some examples, the response may comprise a first response. The first response may be generated based on a first read of the tag of the card 105. The first response may also comprise a version number associated with the card 105. In some examples, the one or more processors 102 of the card 105 may be configured to encrypt the first cryptogram prior to its transmission. For example, the first response may include any combination of a unique identifier of the card 105, a counter 108, a version number of the card 105 that allows for changes in the one or more cryptographic algorithms used, and the first cryptogram that serves as a Message Authentication Code (MAC). In some examples, the first response may comprise a public key digital signature. In other examples, the first response may comprise a MAC inside encrypt structure using one or more symmetric, or derived session, keys. For example, the card 105 may be configured to generate a plurality of session keys, such as a first session key and a second session key, using secret keys combined with the counter 108 of the card 105. The MAC may be generated with the first session key. The MAC may be encrypted with the second session key prior to its transmission for decryption and validation. In some examples, if a public key is also used for subsequent challenge validation, such as challenge validation by the server 120, the public key may be transmitted by the card 105 in the clear or unencrypted, or alternatively the public key may be encrypted along with the MAC prior to transmission from the card 105. In addition, the message used in MAC construction may also include one or more shared secrets for further security. The server 120 may be configured to generate unique derived keys using the unique identifier and master keys. The server 120 may be configured to generate session keys from the unique derived keys and the counter. The server 120 may be configured to decrypt the encrypted MAC from the first cryptogram. The server 120 may be configured to validate the MAC using the session key.


The one or more processors 102 may be configured to transmit the first cryptogram via the communication interface 107. For example, the one or more processors 102 may be configured to transmit the first cryptogram to one or more applications. In some examples, the one or more processors 102 may be configured to transmit the first cryptogram to an application 116 comprising instructions for execution on a second device 110. The one or more processors 102 may be configured to update the counter value after transmission of the first cryptogram.


In some examples, the server 120 may be configured to receive the first cryptogram and the public key from a response transmitted by the one or more processors 102 of card 105. The application 116 of the client device 110 may be configured to transmit the first cryptogram and the public key from the response by the card 105 to the server 120. The server 120 may be configured to decrypt the first cryptogram.


The server 120 may be configured to, based on the first response, generate a first challenge. The server 120 may be configured to encrypt the first challenge with a key, such as a symmetric key. The server 120 may be configured to transmit the encrypted first challenge to the application 116 of the client device 110. In some examples, the server 120 may be configured to transmit the encrypted first challenge based on the version number received from the card 105 or the application 116 of the device 110. Moreover, the server 120 may be configured to generate a random number, such as a secret salt, that is associated with a transaction and also included with the transmitted first challenge. The random number may be generated by the server 120 and may be unique for each transaction. For example, the random number may comprise a string of bits with high entropy. In some examples, the random number may serve as an additional component in the MAC calculation, and include any length. In other examples, the random number may be the same length as the message for combining, such as the one or more logical operations including but not limited to, AND, OR, XOR, NOT.


The first challenge may be associated with a first predetermined time duration. Thus, the first challenge may be time-limited. For example, the server 120 may be configured to generate, after expiration of the first predetermined time duration, one or more additional challenges that are each associated with respective predetermined time durations. For example, the server 120 may be configured to generate, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration. In this manner, a new encrypted challenge associated with a predetermined time duration may be generated and transmitted so as to allow a limited time for decryption.


For example, the first challenge may be combined with a unique identifier of the card 105, a counter of the card 105, and one or more logical operations, including but not limited to, AND, OR, XOR, NOT. In some examples, the first challenge may be encrypted with one or more symmetric keys. For example, the card 105 may include its own symmetric key that is also known by the server 120, or may be derived via key diversification. In some examples, one or more unique derived keys may be generated based on combining one or more secret master keys with the unique identifier of the card 105. In both the card 105 and the server 120, the symmetric key may be independently derived from a master key, and thus the master key and the symmetric key may never be transmitted. In other examples, the first challenge may be encrypted by a private key of the card 105, in which a transmitted public key may be configured to decrypt the first challenge that was encrypted by the private key. In this manner, one or more additional challenges may be encrypted according to these various implementations.


Regarding the key diversification, and without limitation, the card 105 may include a card key, such as a diversified master key, and the server 120 may include its own server key, such as a master key. The card 105 may be configured to generate a diversified key using the diversified master key, one or more cryptographic algorithms, and a counter value. The card 105 may be configured to generate a cryptographic result including the counter value using the one or more cryptographic algorithms and the diversified key. The card 105 may be configured to encrypt transmission data using the one or more cryptographic algorithms and the diversified key to yield encrypted transmission data. The encrypted transmission data and cryptographic result may be transmitted, for example to server 120, by the card 105 for decryption.


The server 120 may be configured to generate an authentication diversified key based on the server master key and a unique identifier. The server 120 may be configured to generate a session key based on the authentication diversified key. The server 120 may be configured to decrypt encrypted transmission data and validate the received cryptographic result using the one or more cryptographic algorithms and the session key.


In some examples, the server 120 may be configured to generate the first challenge based on one or more factors. For example, the one or more factors may include a version number returned in the first read, and a determination of a predetermined type of transaction. For example, the first challenge may be generated based on the version number obtained in the first read. For example, the server 120 may be configured to determine if a transaction associated with the authentication request is a high-risk transaction. The server 120 may be configured to determine if the transaction is high-risk based on evaluation of one or more parameters, including one or more selected from the group of account data, transaction history data, transaction amount, previous time stamps associated with same or similar transactions, prior user authentication attempts and results, abnormal or suspicious geographic locations, abnormal or suspicious merchants, merchants with previous fraudulent activity, and/or any combination thereof.


The application 116 of the client device 110 may be configured to transmit the encrypted first challenge as part of command-application protocol data unit (C-APDU) to the card 105. The one or more processors 102 of the card 105 may be configured to decrypt the encrypted first challenge received from the application 116 of the client device 110. In some examples, the first challenge may be unencrypted and transmitted by the application 116 of the client device 110, and received by the one or more processors 102 of the card 105. The one or more processors 102 of the card 105 may be configured to combine the first challenge with one or more private card keys in such a manner that either a secret key holder, such as the server 120 associated with an issuer of the card 105, may validate that it was combined correctly or via public key verification. When the first challenge is encrypted, the one or more processors 102 of the card 105 may be configured to transmit the decrypted first challenge to the application 116 of the client device 110 as part of a response-application protocol data unit (R-APDU). The response may be a second response and comprise a second cryptogram that incorporates the first challenge into the calculation, which may be combined with the one or more private card keys or as part of the message being signed. The one or more processors 102 of the card 105 may be configured to encrypt the second cryptogram prior to its transmission. The response may also include the random number, such as the secret salt, that is transmitted for verification by comparison with a reference random number or secret salt by the server 120. In some examples, the one or more processors 102 of the card 105 may be configured to perform one or more logical operations, such as an XOR, of the random number with the response prior to the encryption of the second cryptogram. The one or more processors 102 of the card 105 may be configured to transmit, after entry into one or more communication fields of any device, data, such as the second cryptogram. For example, the one or more processors 102 of the card 105 may be configured to transmit, after a second entry into a first communication field of the device, the second cryptogram to the application 116 of second device 110. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.


The server 120 may be configured to receive the second response including the second cryptogram from the one or more processors 102 of the card 105. In some examples, the server 120 may be configured to receive the second response including the second cryptogram from the application 116 of the client device 110. The server 120 may be configured to authenticate the second response by validating the second cryptogram. For example, the server 120 may be configured to decrypt the second cryptogram. Based on a determination of an outcome of the decryption of the second cryptogram, the server 120 may be configured to transmit one or more results to the application 116 of the client device 110.


In some examples, the server 120 may be configured to transmit a successful authentication message if the second cryptogram is validated. For example, the server 120 may be configured to transmit the successful authentication message to the application 116 of the client device 110. In other examples, the server 120 may be configured to transmit an unsuccessful authentication message if the second cryptogram is not validated. For example, the server 120 may be configured to transmit the unsuccessful authentication message to the application 116 of the client device 110. If the second cryptogram is not validated, the server 120 may terminate the authentication process. In another example, the server 120 may be configured to resume the authentication process by, without limitation, resending the authentication request, or generating and encrypting and transmitting a different challenge.



FIG. 2A illustrates one or more first devices 200. First device 200 may reference the same or similar components of first device 105, as explained above with respect to FIG. 1. Although FIGS. 2A and 2B illustrate single instances of components of first device 200, any number of components may be utilized.


First device 200 may be configured to communicate with one or more components of system 100. First device 200 may comprise a contact-based card or contactless card, which may comprise a payment card, such as a credit card, debit card, or gift card, issued by a service provider 205 displayed on the front or back of the contactless card 200. In some examples, the contactless card 200 is not related to a payment card, and may comprise, without limitation, an identification card, a membership card, and a transportation card. In some examples, the payment card may comprise a dual interface contactless payment card. The contactless card 200 may comprise a substrate 210, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 200 may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise be compliant with the ISO/IEC 14443 standard. However, it is understood that the contactless card 200 according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card.


The contactless card 200 may also include identification information 215 displayed on the front and/or back of the card, and a contact pad 220. The contact pad 220 may be configured to establish contact with another communication device, including but not limited to a user device, smart phone, laptop, desktop, or tablet computer. The contactless card 200 may also include processing circuitry, antenna and other components not shown in FIG. 2A. These components may be located behind the contact pad 220 or elsewhere on the substrate 210. The contactless card 200 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 2A).


As illustrated in FIG. 2B, the contact pad 220 of FIG. 2A may include processing circuitry 225 for storing and processing information, including a processor 230, such as a microprocessor, and a memory 235. It is understood that the processing circuitry 225 may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofing hardware, as necessary to perform the functions described herein.


The memory 235 may be a read-only memory, write-once read-multiple memory or read/write memory, e.g., RAM, ROM, and EEPROM, and the contactless card 200 may include one or more of these memories. A read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once then read many times. A write once/read-multiple memory may be programmed at a point in time after the memory has left the factory. Once the memory is programmed, it may not be rewritten, but it may be read many times. A read/write memory may be programmed and re-programed many times after leaving the factory. It may also be read many times.


The memory 235 may be configured to store one or more applets 240, one or more counters 245, and a customer identifier 250. The one or more applets 240 may comprise one or more software applications configured to execute on one or more contactless cards, such as Java Card applet. However, it is understood that applets 240 are not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory. The one or more counters 245 may comprise a numeric counter sufficient to store an integer. The customer identifier 250 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 200, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 250 may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account.


The processor and memory elements of the foregoing exemplary embodiments are described with reference to the contact pad, but the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of the contact pad 220 or entirely separate from it, or as further elements in addition to processor 230 and memory 235 elements located within the contact pad 220.


In some examples, the contactless card 200 may comprise one or more antennas 255. The one or more antennas 255 may be placed within the contactless card 200 and around the processing circuitry 225 of the contact pad 220. For example, the one or more antennas 255 may be integral with the processing circuitry 225 and the one or more antennas 255 may be used with an external booster coil. As another example, the one or more antennas 255 may be external to the contact pad 220 and the processing circuitry 225.


In an embodiment, the coil of contactless card 200 may act as the secondary of an air core transformer. The terminal may communicate with the contactless card 200 by cutting power or amplitude modulation. The contactless card 200 may infer the data transmitted from the terminal using the gaps in the contactless card's power connection, which may be functionally maintained through one or more capacitors. The contactless card 200 may communicate back by switching a load on the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil through interference.



FIG. 3 depicts a method 300 of authentication. FIG. 3 may reference the same or similar components of system 100, and first device 200 of FIG. 2A and FIG. 2B.


At block 305, the method 300 may include transmitting an authentication request. For example, the first request may comprise an authentication request. The application of the client device may be configured to receive the first request. The server may be configured to transmit the authentication request to the application of the client device. The application of the client device may be configured to conduct one or more reads of the card. For example, the application may be configured to conduct a read, such as a near field communication read, of a tag of the card.


At block 310, the method 300 may include receiving a first response that is responsive to the authentication request, the first response comprising a first cryptogram. For example, the card may be configured to transmit the first cryptogram as part of a first response. The card may be configured to transmit, after entry into one or more communication fields of any device, data responsive to the read, such as a first read. For example, the card may be configured to transmit, after a first entry into a first communication field of the device, the first cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof. The first device or card may create the cryptogram using at least one key and a counter value. For example, one or more processors of the card may be configured to create a cryptogram using the at least one key and the counter value. The cryptogram may include the counter value and the transmission data. The card may include a memory containing one or more keys, including the at least one key, a counter value, and the transmission data. The card may further include a communication interface. The first cryptogram may be received, responsive to the authentication request, via a near field communication data exchange format (NDEF) read. The card may be configured to transmit the first cryptogram. The application of the client device may be configured to receive the first cryptogram and a public key from a response transmitted by the card. In some examples, the one or more processors of the card may be configured to generate and transmit, to the application of the client device, the first cryptogram using a shared secret. In some examples, the response may comprise a first response. The first response may be generated based on a first read of the tag of the card. The first response may also comprise a version number associated with the card. In some examples, the card may be configured to encrypt the first cryptogram prior to its transmission. For example, the first response may include any combination of a unique identifier of the card, a counter, a version number of the card that allows for changes in the one or more cryptographic algorithms used, and the first cryptogram that serves as a MAC. In some examples, the first response may comprise a public key digital signature. In other examples, the first response may comprise a MAC inside encrypt structure using one or more symmetric, or derived session, keys. For example, the card may be configured to generate a plurality of session keys, such as a first session key and a second session key, using secret keys combined with the counter of the card. The MAC may be generated with the first session key. The MAC may be encrypted with the second session key prior to its transmission for decryption and validation. In some examples, if a public key is also used for subsequent challenge validation, such as challenge validation by the server, the public key may be transmitted by the card in the clear or unencrypted, or alternatively the public key may be encrypted along with the MAC prior to transmission from the card. In addition, the message used in MAC construction may also include one or more shared secrets for further security. The server may be configured to generate unique derived keys using the unique identifier and master keys. The server may be configured to generate session keys from the unique derived keys and the counter. The server may be configured to decrypt the encrypted MAC from the first cryptogram. The server may be configured to validate the MAC using the session key.


In some examples, the server may be configured to receive the first cryptogram and the public key from a response transmitted by the card. The application of the client device may be configured to transmit the first cryptogram and the public key from the response by the card to the server. The server may be configured to decrypt the first cryptogram.


At block 315, the method 300 may include generating a first challenge based on the first response. For example, the server may be configured to, based on the first response, generate a first challenge. Moreover, the server may be configured to generate a random number, such as a secret salt, that is associated with a transaction and also included with the transmitted first challenge. The random number may be generated by the server and may be unique for each transaction. For example, the random number may comprise a string of bits with high entropy. In some examples, the random number may serve as an additional component in the MAC calculation, and include any length. In other examples, the random number may be the same length as the message for combining, such as the one or more logical operations including but not limited to, AND, OR, XOR, NOT.


In some examples, the server may be configured to generate the first challenge based on one or more factors. For example, the one or more factors may include a version number returned in the first read, and a determination of a predetermined type of transaction. For example, the first challenge may be generated based on the version number obtained in the first read. For example, the server may be configured to determine if a transaction associated with the authentication request is a high-risk transaction. The server may be configured to determine if the transaction is high-risk based on evaluation of one or more parameters, including one or more selected from the group of account data, transaction history data, transaction amount, previous time stamps associated with same or similar transactions, prior user authentication attempts and results, abnormal or suspicious geographic locations, abnormal or suspicious fraudulent merchants, and/or any combination thereof.


The first challenge may be associated with a first predetermined time duration. Thus, the first challenge may be time-limited. For example, the server may be configured to generate, after expiration of the first predetermined time duration, one or more additional challenges that are each associated with respective predetermined time durations. For example, the server may be configured to generate, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration. In this manner, a new encrypted challenge associated with a predetermined time duration may be generated and transmitted so as to allow a limited time for decryption.


At block 320, the method 300 may include encrypting the first challenge with a symmetric key. The server may be configured to encrypt the first challenge with a key, such as a symmetric key. In other examples, the application of the device may be configured to encrypt the first challenge with the key. For example, the first challenge may be combined with a unique identifier of the card, a counter of the card, and one or more logical operations, including but not limited to, AND, OR, XOR, NOT. In some examples, the first challenge may be encrypted with one or more symmetric keys. For example, the card may include its own symmetric key that is also known by the server, or may be derived via key diversification. In some examples, one or more unique derived keys may be generated based on combining one or more secret master keys with the unique identifier of the card. In both the card and the server, the symmetric key may be independently derived from a master key, and thus the master key and the symmetric key may never be transmitted. In other examples, the first challenge may be encrypted by a private key of the card, in which a transmitted public key may be configured to decrypt the first challenge that was encrypted by the private key.


Regarding the key diversification, and without limitation, the card may include a card key, such as a diversified master key, and the server may include its own server key, such as a master key. The card may be configured to generate a diversified key using the diversified master key, one or more cryptographic algorithms, and a counter value. The card may be configured to generate a cryptographic result including the counter value using the one or more cryptographic algorithms and the diversified key. The card may be configured to encrypt transmission data using the one or more cryptographic algorithms and the diversified key to yield encrypted transmission data. The encrypted transmission data and cryptographic result may be transmitted, for example to server, by the card for decryption.


The server may be configured to generate an authentication diversified key based on the server master key and a unique identifier. The server may be configured to generate a session key based on the authentication diversified key. The server may be configured to decrypt encrypted transmission data and validate the received cryptographic result using the one or more cryptographic algorithms and the session key.


At block 325, the method 300 may include transmitting the first challenge. For example, the server may be configured to transmit the encrypted first challenge to the application of the client device. In some examples, the server may be configured to transmit the encrypted first challenge based on the version number received from the card or the application of the device. In some examples, the application of the client device may be configured to transmit the encrypted first challenge as part of command-application protocol data unit (C-APDU) to the card.


At block 330, the method 300 may include receiving a second response that is responsive to the first challenge, the second response comprising a second cryptogram. For example, the server may be configured to receive the second response including the second cryptogram from the card. In some examples, the server may be configured to receive the second response including the second cryptogram from the application of the client device. The card may be configured to decrypt the encrypted first challenge received from the application of the client device. In some examples, the first challenge may be unencrypted and transmitted by the application of the client device, and received by the one or more processors of the card. The one or more processors of the card may be configured to combine the first challenge with one or more private card keys in such a manner that either a secret key holder, such as the server associated with an issuer of the card, may validate that it was combined correctly or via public key verification. When the first challenge is encrypted, the card may be configured to transmit the decrypted first challenge to the application of the client device as part of a response-application protocol data unit (R-APDU). The response may be a second response and comprise a second cryptogram that incorporates the first challenge into the calculation, which may be combined with the one or more private card keys or as part of the message being signed. The card may be configured to encrypt the second cryptogram prior to its transmission. The response may also include the random number, such as the secret salt, that is transmitted for verification by comparison with a reference random number or secret salt by the server. In some examples, the card may be configured to perform one or more logical operations, e.g., AND, OR, XOR, NOT, of the random number with the response prior to the cryptogram encryption. The card may be configured to transmit, after entry into one or more communication fields of any device, data, such as the second cryptogram. For example, the card may be configured to transmit, after a second entry into a first communication field of the device, the second cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.


At block 335, the method 300 may include authenticating the second response. For example, the server may be configured to authenticate the second response by validating the second cryptogram. For example, the server may be configured to decrypt the second cryptogram. Based on a determination of an outcome of the decryption of the second cryptogram, the server may be configured to transmit one or more results to the application of the client device.



FIG. 4 depicts a sequence diagram 400 of a process for authentication according to an exemplary embodiment. FIG. 4 may reference the same or similar components of system 100, first device 200 of FIG. 2A and FIG. 2B, and method 300 of FIG. 3.


At step 405, a server may be configured to transmit a first request. For example, the first request may comprise an authentication request. An application of a client device may be configured to receive the first request. At step 410, the application of the client device may be configured to conduct one or more reads of a card as part of the first request. For example, the application may be configured to conduct a read, such as a near field communication read, of a tag of the card.


At step 415, the card may be configured to transmit the first cryptogram. The card may be configured to transmit, after entry into one or more communication fields of any device, data responsive to the read, such as a first read, via a communication interface. For example, the card may be configured to transmit, after a first entry into a first communication field of the device, the first cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof. The application of the client device may be configured to receive the first cryptogram and a public key from a response transmitted by the card. In some examples, the one or more processors of the card may be configured to generate and transmit, to the application of the client device, the first cryptogram using a shared secret. In some examples, the response may comprise a first response. The first response may be generated based on a first read of the tag of the card. The first response may also comprise a version number associated with the card. In some examples, the card may be configured to encrypt the first cryptogram prior to its transmission. For example, the first response may include any combination of a unique identifier of the card, a counter, a version number of the card that allows for changes in the one or more cryptographic algorithms used, and the first cryptogram that serves as a MAC. In some examples, the first response may comprise a public key digital signature. In other examples, the first response may comprise a MAC inside encrypt structure using one or more symmetric, or derived session, keys. For example, the card may be configured to generate a plurality of session keys, such as a first session key and a second session key, using secret keys combined with the counter of the card. The MAC may be generated with the first session key. The MAC may be encrypted with the second session key prior to its transmission for decryption and validation. In some examples, if a public key is also used for subsequent challenge validation, such as challenge validation by the server, the public key may be transmitted by the card in the clear or unencrypted, or alternatively the public key may be encrypted along with the MAC prior to transmission from the card. In addition, the message used in MAC construction may also include one or more shared secrets for further security. The server may be configured to generate unique derived keys using the unique identifier and master keys. The server may be configured to generate session keys from the unique derived keys and the counter. The server may be configured to decrypt the encrypted MAC from the first cryptogram. The server may be configured to validate the MAC using the session key.


At step 420, the application of the client device may be configured to transmit the first cryptogram and the public key from the response by the card to the server. In some examples, the server may be configured to receive the first cryptogram and the public key from a response transmitted by the card. The server may be configured to decrypt the first cryptogram.


The server may be configured to, based on the first response, generate a first challenge. The server may be configured to encrypt the first challenge with a key, such as a symmetric key. Moreover, the server may be configured to generate a random number, such as a secret salt, that is associated with a transaction and also included with the transmitted first challenge. The random number may be generated by the server and may be unique for each transaction. For example, the first challenge may be combined with a unique identifier of the card, a counter of the card, and one or more logical operations, including but not limited to, AND, OR, XOR, NOT. In some examples, the first challenge may be encrypted with one or more symmetric keys. For example, the card may include its own symmetric key that is also known by the server, or may be derived via key diversification. In some examples, one or more unique derived keys may be generated based on combining one or more secret master keys with the unique identifier of the card. In both the card and the server, the symmetric key may be independently derived from a master key, and thus the master key and the symmetric key may never be transmitted. In other examples, the first challenge may be encrypted by a private key of the card, in which a transmitted public key may be configured to decrypt the first challenge that was encrypted by the private key.


Regarding the key diversification, and without limitation, the card may include a card key, such as a diversified master key, and the server may include its own server key, such as a master key. The card may be configured to generate a diversified key using the diversified master key, one or more cryptographic algorithms, and a counter value. The card may be configured to generate a cryptographic result including the counter value using the one or more cryptographic algorithms and the diversified key. The card may be configured to encrypt transmission data using the one or more cryptographic algorithms and the diversified key to yield encrypted transmission data. The encrypted transmission data and cryptographic result may be transmitted, for example to server, by the card for decryption.


The server may be configured to generate an authentication diversified key based on the server master key and a unique identifier. The server may be configured to generate a session key based on the authentication diversified key. The server may be configured to decrypt encrypted transmission data and validate the received cryptographic result using the one or more cryptographic algorithms and the session key.


The first challenge may be associated with a first predetermined time duration. Thus, the first challenge may be time-limited. For example, the server may be configured to generate, after expiration of the first predetermined time duration, one or more additional challenges that are each associated with respective predetermined time durations. For example, the server may be configured to generate, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration. In this manner, a new encrypted challenge associated with a predetermined time duration may be generated and transmitted so as to allow a limited time for decryption.


In some examples, the server may be configured to generate the first challenge based on one or more factors. For example, the one or more factors may include a version number returned in the first read, and a determination of a predetermined type of transaction. For example, the first challenge may be generated based on the version number obtained in the first read. For example, the server may be configured to determine if a transaction associated with the authentication request is a high-risk transaction. The server may be configured to determine if the transaction is high-risk based on evaluation of one or more parameters, including one or more selected from the group of account data, transaction history data, transaction amount, previous time stamps associated with same or similar transactions, prior user authentication attempts and results, abnormal or suspicious geographic locations, abnormal or suspicious fraudulent merchants, and/or any combination thereof.


At step 425, the server may be configured to transmit the encrypted first challenge to the application of the client device. In some examples, the server may be configured to transmit the encrypted first challenge based on the version number received from the card or the application of the device. The application of the client device may be configured to receive the encrypted first challenge from the server.


At step 430, the application of the client device may be configured to transmit the encrypted first challenge as part of command-application protocol data unit (C-APDU) to the card.


At step 435, the card may be configured to decrypt the encrypted first challenge received from the application of the client device. In some examples, the first challenge may be unencrypted and transmitted by the application of the client device, and received by the one or more processors of the card. The one or more processors of the card may be configured to combine the first challenge with one or more private card keys in such a manner that either a secret key holder, such as the server associated with an issuer of the card, may validate that it was combined correctly or via public key verification. When the first challenge is encrypted, the card may be configured to transmit the decrypted first challenge to the application of the client device as part of a response-application protocol data unit (R-APDU). The response may be a second response and comprise a second cryptogram that incorporates the first challenge into the calculation, which may be combined with the one or more private card keys or as part of the message being signed. The card may be configured to encrypt the second cryptogram prior to its transmission. The response may also include the random number, such as the secret salt, that is transmitted for verification by comparison with a reference random number or secret salt by the server. In some examples, the card may be configured to perform one or more logical operations, e.g., AND, OR, XOR, NOT, of the random number with the response prior to the encryption of the second cryptogram. The card may be configured to transmit, after entry into one or more communication fields of any device, data, such as the second cryptogram. For example, the card may be configured to transmit, after a second entry into a first communication field of the device, the second cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.


At step 440, the server may be configured to receive the second response including the second cryptogram. In some examples, the server may be configured to receive the second response including the second cryptogram from the application of the client device. The server may be configured to authenticate the second response by validating the second cryptogram. For example, the server may be configured to decrypt the second cryptogram. Based on a determination of an outcome of the decryption of the second cryptogram, the server may be configured to transmit one or more results to the application of the client device.


At step 445, the server may be configured to transmit a successful authentication message if the second cryptogram is validated. For example, the server may be configured to transmit the successful authentication message to the application of the client device. In other examples, the server may be configured to transmit an unsuccessful authentication message if the second cryptogram is not validated. For example, the server may be configured to transmit the unsuccessful authentication message to the application of the client device. If the second cryptogram is not validated, the server may terminate the authentication process. In another example, the server may be configured to resume the authentication process by, without limitation, resending the authentication request, or generating and encrypting and transmitting a different challenge.



FIG. 5 depicts a method of 500 of authentication according to an exemplary embodiment. FIG. 5 may reference the same or similar components of system 100, first device 200 of FIG. 2A and FIG. 2B, method 300 of FIG. 3, and sequence diagram 400 of FIG. 4.


At block 505, the method 500 may include generating, in response to an authentication request, a first cryptogram based on a read of a tag. For example, an application of the client device may be configured to conduct one or more reads of the card. For example, the application may be configured to conduct a read, such as a near field communication read, of a tag of the card.


At block 510, the method 500 may include transmitting a first response including the first cryptogram and a public key and a version number. The first cryptogram may be received, upon request, via a near field communication data exchange format (NDEF) read. The card may be configured to transmit the first cryptogram. The card may be configured to transmit, after entry into one or more communication fields of any device, data responsive to the read, such as a first read. For example, the card may be configured to transmit, after a first entry into a first communication field of the device, the first cryptogram. In some examples, the one or more processors of the card may be configured to generate and transmit, to the application of the client device, the first cryptogram using a shared secret. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof. The first response may be generated based on a first read of the tag of the card. The first response may also comprise a version number associated with the card. In some examples, the card may be configured to encrypt the first cryptogram prior to its transmission. For example, the first response may include any combination of a unique identifier of the card, a counter, a version number of the card that allows for changes in the one or more cryptographic algorithms used, and the first cryptogram that serves as a MAC. In some examples, the first response may comprise a public key digital signature. In other examples, the first response may comprise a MAC inside encrypt structure using one or more symmetric, or derived session, keys. For example, the card may be configured to generate a plurality of session keys, such as a first session key and a second session key, using secret keys combined with the counter of the card. The MAC may be generated with the first session key. The MAC may be encrypted with the second session key prior to its transmission for decryption and validation. In some examples, if a public key is also used for subsequent challenge validation, such as challenge validation by the server, the public key may be transmitted by the card in the clear or unencrypted, or alternatively the public key may be encrypted along with the MAC prior to transmission from the card. In addition, the message used in MAC construction may also include one or more shared secrets for further security. The server may be configured to generate unique derived keys using the unique identifier and master keys. The server may be configured to generate session keys from the unique derived keys and the counter. The server may be configured to decrypt the encrypted MAC from the first cryptogram. The server may be configured to validate the MAC using the session key.


At block 515, the method 500 may include receiving, via a command-application protocol data unit (C-APDU), an encrypted first challenge. For example, a server may be configured to, based on the received and authenticated first response, generate a first challenge. The server may be configured to decrypt the first cryptogram transmitted by the card. The server may be configured to encrypt the first challenge with a key, such as a symmetric key. For example, the first challenge may be combined with a unique identifier of the card, a counter of the card, and one or more logical operations, including but not limited to, AND, OR, XOR, NOT. In some examples, the first challenge may be encrypted with one or more symmetric keys. For example, the card may include its own symmetric key that is also known by the server, or may be derived via key diversification. In some examples, one or more unique derived keys may be generated based on combining one or more secret master keys with the unique identifier of the card. In both the card and the server, the symmetric key may be independently derived from a master key, and thus the master key and the symmetric key may never be transmitted. In other examples, the first challenge may be encrypted by a private key of the card, in which a transmitted public key may be configured to decrypt the first challenge that was encrypted by the private key.


Regarding the key diversification, and without limitation, the card may include a card key, such as a diversified master key, and the server may include its own server key, such as a master key. The card may be configured to generate a diversified key using the diversified master key, one or more cryptographic algorithms, and a counter value. The card may be configured to generate a cryptographic result including the counter value using the one or more cryptographic algorithms and the diversified key. The card may be configured to encrypt transmission data using the one or more cryptographic algorithms and the diversified key to yield encrypted transmission data. The encrypted transmission data and cryptographic result may be transmitted, for example to server, by the card for decryption.


The server may be configured to generate an authentication diversified key based on the server master key and a unique identifier. The server may be configured to generate a session key based on the authentication diversified key. The server may be configured to decrypt encrypted transmission data and validate the received cryptographic result using the one or more cryptographic algorithms and the session key.


The server may be configured to transmit the encrypted first challenge to the application of the client device. In some examples, the server may be configured to transmit the encrypted first challenge based on the version number received from the card or the application of the device. Moreover, the server may be configured to generate a random number, such as a secret salt, that is associated with a transaction and also included with the transmitted first challenge. The random number may be generated by the server and may be unique for each transaction. For example, the random number may comprise a string of bits with high entropy. In some examples, the random number may serve as an additional component in the MAC calculation, and include any length. In other examples, the random number may be the same length as the message for combining, such as the one or more logical operations including but not limited to, AND, OR, XOR, NOT.


The first challenge may be associated with a first predetermined time duration. Thus, the first challenge may be time-limited. For example, the server may be configured to generate, after expiration of the first predetermined time duration, one or more additional challenges that are each associated with respective predetermined time durations. For example, the server may be configured to generate, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration. In this manner, a new encrypted challenge associated with a predetermined time duration may be generated and transmitted so as to allow a limited time for decryption.


In some examples, the server may be configured to generate the first challenge based on one or more factors. For example, the one or more factors may include a version number returned in the first read, and a determination of a predetermined type of transaction. For example, the first challenge may be generated based on the version number obtained in the first read. For example, the server may be configured to determine if a transaction associated with the authentication request is a high-risk transaction. The server may be configured to determine if the transaction is high-risk based on evaluation of one or more parameters, including one or more selected from the group of account data, transaction history data, transaction amount, previous time stamps associated with same or similar transactions, prior user authentication attempts and results, abnormal or suspicious geographic locations, abnormal or suspicious fraudulent merchants, and/or any combination thereof.


At block 520, the method 500 may include decrypting the encrypted first challenge. For example, the card may be configured to decrypt the encrypted first challenge received from the application of the client device. In some examples, the first challenge may be unencrypted and transmitted by the application of the client device, and received by the one or more processors of the card. The one or more processors of the card may be configured to combine the first challenge with one or more private card keys in such a manner that either a secret key holder, such as the server associated with an issuer of the card, may validate that it was combined correctly or via public key verification.


At block 525, the method 500 may include generating a second cryptogram. The response may be a second response and comprise a second cryptogram that incorporates the first challenge into the calculation, which may be combined with the one or more private card keys or as part of the message being signed. The card may be configured to encrypt the second cryptogram prior to its transmission. In some examples, the card may be configured to perform one or more logical operations, e.g., AND, OR, XOR, NOT, of the random number with the response prior to the encryption of the second cryptogram.


At block 530, the method 500 may include transmitting, responsive to the command-application protocol data unit, a second response including the second cryptogram. The card may be configured to transmit the decrypted first challenge to the application of the client device as part of a response-application protocol data unit (R-APDU). The response may also include the random number, such as the secret salt, that is transmitted for verification by comparison with a reference random number or secret salt by the server. The card may be configured to transmit, after entry into one or more communication fields of any device, data, such as the second cryptogram. For example, the card may be configured to transmit, after a second entry into a first communication field of the device, the second response including second cryptogram and random number. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.



FIG. 6 depicts a method 600 of authentication according to an exemplary embodiment. FIG. 6 may reference the same or similar components of system 100, first device 200 of FIG. 2A and FIG. 2B, method 300 of FIG. 3, sequence diagram 400 of FIG. 4, and method 500 of FIG. 5.


At block 605, the method 600 may include generating a challenge. For example, the server may be configured to generate the challenge. In some examples, the application of the device may be configured to generate the challenge. Moreover, the server or application of the device may be configured to generate a random number, such as a secret salt, that is associated with a transaction and also included with the transmitted challenge. The random number may be generated by the server or the application of the device and may be unique for each transaction. For example, the random number may comprise a string of bits with high entropy. In some examples, the random number may serve as an additional component in the MAC calculation, and include any length. In other examples, the random number may be the same length as the message for combining, such as the one or more logical operations including but not limited to, AND, OR, XOR, NOT.


In some examples, the server may be configured to generate the challenge based on one or more factors. For example, the one or more factors may include a version number associated with a card and returned in a read, and a determination of a predetermined type of transaction. For example, the challenge may be generated based on the version number obtained in the read. The server may be configured to determine if a transaction associated with the authentication request is a high-risk transaction. The server may be configured to determine if the transaction is high-risk based on evaluation of one or more parameters, including one or more selected from the group of account data, transaction history data, transaction amount, previous time stamps associated with same or similar transactions, prior user authentication attempts and results, abnormal or suspicious geographic locations, abnormal or suspicious fraudulent merchants, and/or any combination thereof.


The challenge may be associated with a predetermined time duration. Thus, the challenge may be time-limited. For example, the server may be configured to generate, after expiration of the predetermined time duration, one or more additional challenges that are each associated with respective predetermined time durations. For example, the server may be configured to generate, after expiration of the predetermined time duration, a second challenge associated with a second predetermined time duration. In this manner, a new encrypted challenge associated with a predetermined time duration may be generated and transmitted so as to allow a limited time for decryption.


At block 610, the method 600 may include encrypting the challenge. For example, the server may be configured to encrypt the challenge with a key, such as a symmetric key. In other examples, the application of the device may be configured to encrypt the challenge with the key. For example, the challenge may be combined with a unique identifier of the card, a counter of the card, and one or more logical operations, including but not limited to, AND, OR, XOR, NOT. In some examples, the challenge may be encrypted with one or more symmetric keys. For example, the card may include its own symmetric key that is also known by the server or the application comprising instructions for execution on the device, or may be derived via key diversification. In some examples, one or more unique derived keys may be generated based on combining one or more secret master keys with the unique identifier of the card. In the card and the server or the application, the symmetric key be independently derived from a master key, and is thus never transmitted. In other examples, the first challenge may be encrypted by a private key of the card, in which a transmitted public key may be configured to decrypt the first challenge that was encrypted by the private key.


Regarding the key diversification, and without limitation, the card may include a card key, such as a diversified master key, and the server may include its own server key, such as a master key. The card may be configured to generate a diversified key using the diversified master key, one or more cryptographic algorithms, and a counter value. The card may be configured to generate a cryptographic result including the counter value using the one or more cryptographic algorithms and the diversified key. The card may be configured to encrypt transmission data using the one or more cryptographic algorithms and the diversified key to yield encrypted transmission data. The encrypted transmission data and cryptographic result may be transmitted, for example to server, by the card for decryption.


The server may be configured to generate an authentication diversified key based on the server master key and a unique identifier. The server may be configured to generate a session key based on the authentication diversified key. The server may be configured to decrypt encrypted transmission data and validate the received cryptographic result using the one or more cryptographic algorithms and the session key.


At block 615, the method 600 may include transmitting the challenge. For example, the server may be configured to transmit the encrypted challenge to the application of the client device. In some examples, the server may be configured to transmit the encrypted challenge based on the version number received from the card or the application of the device. In other examples, the application of the device may be configured to transmit the challenge. For example, the application of the client device may be configured to transmit the encrypted challenge as part of command-application protocol data unit (C-APDU) to the card.


At block 620, the method 600 may include receiving a response. For example, the server may be configured to receive a response. In other examples, the application of the device may be configured to receive the response. The response may be transmitted responsive to the transmitted challenge. The server may be configured to receive the response including a cryptogram from the card. In some examples, the server may be configured to receive the response including the cryptogram from the application of the client device.


The card may be configured to decrypt the encrypted challenge received from the application of the client device. In some examples, the first challenge may be unencrypted and transmitted by the application of the client device, and received by the one or more processors of the card. The one or more processors of the card may be configured to combine the first challenge with one or more private card keys in such a manner that either a secret key holder, such as the server associated with an issuer of the card, may validate that it was combined correctly or via public key verification. When the first challenge is encrypted, the card may be configured to transmit the decrypted challenge to the application of the client device as part of a response-application protocol data unit (R-APDU). The response may be a response and comprise a cryptogram. The card may be configured to encrypt the cryptogram prior to its transmission. The response may also include the random number, such as the secret salt, that is transmitted for verification by comparison with a reference random number or secret salt by the server. In some examples, the card may be configured to perform one or more logical operations, e.g., AND, OR, XOR, NOT, of the random number with the response prior to the cryptogram encryption. The card may be configured to transmit, after entry into one or more communication fields of any device, data, such as the cryptogram. For example, the card may be configured to transmit, after an entry into a communication field of the device, the cryptogram. Without limitation, each entry may be associated with a tap, a swipe, a wave, and/or any combination thereof.


At block 625, the method 600 may include decrypting the cryptogram. For example, the server may be configured to decrypt the received cryptogram from the response. In other examples, the application of the device may be configured to decrypt the received cryptogram from the response. The server may be configured to authenticate the response by validating the cryptogram. For example, the server may be configured to decrypt the cryptogram.


At block 630, the method 600 may include transmitting an outcome based on a status of decryption of the cryptogram. For example, based on a determination of an outcome of the decryption of the cryptogram, the server may be configured to transmit one or more results to the application of the client device. The one or more results may be indicative of the decryption status. In some examples, the server may be configured to transmit a successful authentication message if the cryptogram is validated. For example, the server may be configured to transmit the successful authentication message to the application of the client device. In other examples, the server may be configured to transmit an unsuccessful authentication message if the cryptogram is not validated. For example, the server may be configured to transmit the unsuccessful authentication message to the application of the client device. If the cryptogram is not validated, the server may terminate the authentication process. In another example, the server may be configured to resume the authentication process by, without limitation, resending the authentication request, or generating and encrypting and transmitting a different challenge.


It is further noted that the systems and methods described herein may be tangibly embodied in one of more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, read only memory (ROM), random access memory (RAM), as well as other physical media capable of data storage. For example, data storage may include random access memory (RAM) and read only memory (ROM), which may be configured to access and store data and information and computer program instructions. Data storage may also include storage media or other suitable type of memory (e.g., such as, for example, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, flash drives, any type of tangible and non-transitory storage medium), where the files that comprise an operating system, application programs including, for example, web browser application, email application and/or other applications, and data files may be stored. The data storage of the network-enabled computer systems may include electronic information, files, and documents stored in various ways, including, for example, a flat file, indexed file, hierarchical database, relational database, such as a database created and maintained with software from, for example, Oracle® Corporation, Microsoft® Excel file, Microsoft® Access file, a solid state storage device, which may include a flash array, a hybrid array, or a server-side product, enterprise storage, which may include online or cloud storage, or any other storage mechanism. Moreover, the figures illustrate various components (e.g., servers, computers, processors, etc.) separately. The functions described as being performed at various components may be performed at other components, and the various components may be combined or separated. Other modifications also may be made.


In the preceding specification, various embodiments have been described with references to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense.

Claims
  • 1. An authentication server, comprising: a processor; anda memory,wherein the processor: transmits an authentication request;receives a first response that is responsive to the authentication request, the first response comprising a first cryptogram;generates a first challenge based on the first response;encrypts the first challenge with a symmetric key;generates a secret salt that is associated with a transaction;transmits the first challenge after it has been encrypted and transmits the secret salt along with the encrypted first challenge;receives a second response that is responsive to the first challenge, the second response comprising a second cryptogram, wherein the second cryptogram is generated using the first challenge in combination with one or more private card keys, and comprises the secret salt;authenticates the second response by: decrypting the second cryptogram, andvalidating the decrypted second cryptogram using a session key by comparing the secret salt from the second cryptogram with a reference secret salt; andtransmits, to a client device, one or more authentication messages as a result of the validation of the decrypted second cryptogram.
  • 2. The authentication server of claim 1, wherein the first response is generated based on a first read of a tag.
  • 3. The authentication server of claim 2, wherein the first read of the tag includes a read of a tag of a contactless card and the first response includes a version number associated with the contactless card.
  • 4. The authentication server of claim 1, wherein the first challenge is associated with a first predetermined time duration.
  • 5. The authentication server of claim 4, wherein the processor generates, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration.
  • 6. The authentication server of claim 1, wherein the processor generates the first challenge based on a determination of a predetermined type of transaction.
  • 7. The authentication server of claim 1, wherein the processor receives a public key and a version number.
  • 8. The authentication server of claim 7, wherein the first challenge is transmitted based on the version number.
  • 9. A method of authentication, the method comprising the steps of: transmitting an authentication request;receiving a first response that is responsive to the authentication request, the first response comprising a first cryptogram;generating a first challenge based on the first response;encrypting the first challenge with a symmetric key;generating a secret salt that is associated with a transaction;transmitting the first challenge after it has been encrypted and transmitting the secret salt along with the encrypted first challenge;receiving a second response that is responsive to the first challenge, the second response comprising a second cryptogram, wherein the second cryptogram is generated using the first challenge in combination with one or more private card keys, and comprises the secret salt;authenticating the second response by: decrypting the second cryptogram, andvalidating the decrypted second cryptogram using a session key by comparing the secret salt from the second cryptogram with a reference secret salt; andtransmitting, to a client device, one or more authentication messages as a result of the validation of the decrypted second cryptogram.
  • 10. The method of claim 9, wherein the first response is generated based on a first read of a tag.
  • 11. The method of claim 10, wherein the first read of the tag includes a read of a tag of a contactless card and the first response includes a version number associated with the contactless card.
  • 12. The method of claim 9, wherein the first challenge is associated with a first predetermined time duration.
  • 13. The method of claim 12, further comprising generating, after expiration of the first predetermined time duration, a second challenge associated with a second predetermined time duration.
  • 14. The method of claim 9, further comprising generating the first challenge based on a determination of a predetermined type of transaction.
  • 15. The method of claim 9, further comprising receiving a public key and a version number.
  • 16. The method of claim 15, wherein the first challenge is transmitted based on the version number.
  • 17. The method of claim 9, further comprising decrypting the second response including the secret salt.
  • 18. The method of claim 9, further comprising transmitting, based on determining an outcome of decryption status of the second cryptogram, one or more messages indicative of the decryption status.
  • 19. The method of claim 9, wherein the first cryptogram is received via a near field communication data exchange format (NDEF) read.
  • 20. A computer readable non-transitory medium comprising computer executable instructions that, when executed on a processor, perform procedures comprising the steps of: transmitting an authentication request;receiving a first response that is responsive to the authentication request, the first response comprising a first cryptogram;generating a first challenge based on the first response;encrypting the first challenge with a symmetric key;generating a secret salt that is associated with a transaction;transmitting the first challenge after it has been encrypted and transmitting the secret salt along with the encrypted first challenge;receiving a second response that is responsive to the first challenge, the second response comprising a second cryptogram, wherein the second cryptogram is generated using the first challenge in combination with one or more private card keys, and comprises the secret salt;authenticating the second response by: decrypting the second cryptogram, andvalidating the decrypted second cryptogram using a session key by comparing the secret salt from the second cryptogram with a reference secret salt; andtransmitting, to a client device, one or more authentication messages as a result of the validation of the decrypted second cryptogram.
US Referenced Citations (552)
Number Name Date Kind
4683553 Mollier Jul 1987 A
4827113 Rikuna May 1989 A
4910773 Hazard et al. Mar 1990 A
5036461 Elliott et al. Jul 1991 A
5363448 Koopman, Jr. et al. Nov 1994 A
5377270 Koopman, Jr. et al. Dec 1994 A
5533126 Hazard Jul 1996 A
5537314 Kanter Jul 1996 A
5592553 Guski et al. Jan 1997 A
5616901 Crandall Apr 1997 A
5666415 Kaufman Sep 1997 A
5764789 Pare, Jr. et al. Jun 1998 A
5768373 Lohstroh et al. Jun 1998 A
5778072 Samar Jul 1998 A
5796827 Coppersmith et al. Aug 1998 A
5832090 Raspotnik Nov 1998 A
5883810 Franklin et al. Mar 1999 A
5901874 Deters May 1999 A
5929413 Gardner Jul 1999 A
5960411 Hartman et al. Sep 1999 A
6021203 Douceur et al. Feb 2000 A
6049328 Vanderheiden Apr 2000 A
6058373 Blinn et al. May 2000 A
6061666 Do et al. May 2000 A
6105013 Curry et al. Aug 2000 A
6199114 White et al. Mar 2001 B1
6199762 Hohle Mar 2001 B1
6216227 Goldstein et al. Apr 2001 B1
6227447 Campisano May 2001 B1
6282522 Davis et al. Aug 2001 B1
6324271 Sawyer et al. Nov 2001 B1
6342844 Rozin Jan 2002 B1
6367011 Lee et al. Apr 2002 B1
6402028 Graham, Jr. et al. Jun 2002 B1
6438550 Doyle et al. Aug 2002 B1
6501847 Helot et al. Dec 2002 B2
6631197 Taenzer Oct 2003 B1
6641050 Kelley et al. Nov 2003 B2
6655585 Shinn Dec 2003 B2
6662020 Aaro et al. Dec 2003 B1
6721706 Strubbe et al. Apr 2004 B1
6731778 Oda et al. May 2004 B1
6779115 Naim Aug 2004 B1
6792533 Jablon Sep 2004 B2
6829711 Kwok et al. Dec 2004 B1
6834271 Hodgson et al. Dec 2004 B1
6834795 Rasmussen et al. Dec 2004 B1
6852031 Rowe Feb 2005 B1
6865547 Brake, Jr. et al. Mar 2005 B1
6873260 Lancos et al. Mar 2005 B2
6877656 Jaros et al. Apr 2005 B1
6889198 Kawan May 2005 B2
6905411 Nguyen et al. Jun 2005 B2
6910627 Simpson-Young et al. Jun 2005 B1
6971031 Haala Nov 2005 B2
6990588 Yasukura Jan 2006 B1
7006986 Sines et al. Feb 2006 B1
7085931 Smith et al. Aug 2006 B1
7127605 Montgomery et al. Oct 2006 B1
7128274 Kelley et al. Oct 2006 B2
7140550 Ramachandran Nov 2006 B2
7152045 Hoffman Dec 2006 B2
7165727 de Jong Jan 2007 B2
7175076 Block et al. Feb 2007 B1
7202773 Oba et al. Apr 2007 B1
7206806 Pineau Apr 2007 B2
7232073 de Jong Jun 2007 B1
7246752 Brown Jul 2007 B2
7254569 Goodman et al. Aug 2007 B2
7263507 Brake, Jr. et al. Aug 2007 B1
7270276 Vayssiere Sep 2007 B2
7278025 Saito et al. Oct 2007 B2
7287692 Patel et al. Oct 2007 B1
7290709 Tsai et al. Nov 2007 B2
7306143 Bonneau, Jr. et al. Dec 2007 B2
7319986 Praisner et al. Jan 2008 B2
7325132 Takayama et al. Jan 2008 B2
7373515 Owen et al. May 2008 B2
7374099 de Jong May 2008 B2
7375616 Rowse et al. May 2008 B2
7380710 Brown Jun 2008 B2
7424977 Smets et al. Sep 2008 B2
7453439 Kushler et al. Nov 2008 B1
7472829 Brown Jan 2009 B2
7487357 Smith et al. Feb 2009 B2
7568631 Gibbs et al. Aug 2009 B2
7584153 Brown et al. Sep 2009 B2
7597250 Finn Oct 2009 B2
7628322 Holtmanns et al. Dec 2009 B2
7652578 Braun et al. Jan 2010 B2
7689832 Talmor et al. Mar 2010 B2
7703142 Wilson et al. Apr 2010 B1
7748609 Sachdeva et al. Jul 2010 B2
7748617 Gray Jul 2010 B2
7748636 Finn Jul 2010 B2
7762457 Bonalle et al. Jul 2010 B2
7789302 Tame Sep 2010 B2
7793851 Mullen Sep 2010 B2
7796013 Murakami et al. Sep 2010 B2
7801799 Brake, Jr. et al. Sep 2010 B1
7801829 Gray et al. Sep 2010 B2
7805755 Brown et al. Sep 2010 B2
7809643 Phillips et al. Oct 2010 B2
7827115 Weller et al. Nov 2010 B2
7828214 Narendra et al. Nov 2010 B2
7848746 Juels Dec 2010 B2
7853788 Fascenda Dec 2010 B2
7882553 Tuliani Feb 2011 B2
7900048 Andersson Mar 2011 B2
7908216 Davis et al. Mar 2011 B1
7922082 Muscato Apr 2011 B2
7933589 Mamdani et al. Apr 2011 B1
7949559 Freiberg May 2011 B2
7954716 Narendra et al. Jun 2011 B2
7954723 Charrat Jun 2011 B2
7962369 Rosenberg Jun 2011 B2
7993197 Mamdani et al. Aug 2011 B2
8005426 Huomo et al. Aug 2011 B2
8010405 Bortolin et al. Aug 2011 B1
RE42762 Shin Sep 2011 E
8041954 Plesman Oct 2011 B2
8060012 Sklovsky et al. Nov 2011 B2
8074877 Mullen et al. Dec 2011 B2
8082450 Frey et al. Dec 2011 B2
8095113 Kean et al. Jan 2012 B2
8099332 Lemay et al. Jan 2012 B2
8103249 Markison Jan 2012 B2
8108687 Ellis et al. Jan 2012 B2
8127143 Abdallah et al. Feb 2012 B2
8135648 Oram et al. Mar 2012 B2
8140010 Symons et al. Mar 2012 B2
8141136 Lee et al. Mar 2012 B2
8150321 Winter et al. Apr 2012 B2
8150767 Wankmueller Apr 2012 B2
8186602 Itay et al. May 2012 B2
8196131 von Behren et al. Jun 2012 B1
8215563 Levy et al. Jul 2012 B2
8224753 Atef et al. Jul 2012 B2
8232879 Davis Jul 2012 B2
8233841 Griffin et al. Jul 2012 B2
8245292 Buer Aug 2012 B2
8249654 Zhu Aug 2012 B1
8266451 Leydier et al. Sep 2012 B2
8285329 Zhu Oct 2012 B1
8302872 Mullen Nov 2012 B2
8312519 Bailey et al. Nov 2012 B1
8316237 Felsher et al. Nov 2012 B1
8332272 Fisher Dec 2012 B2
8365988 Medina, III et al. Feb 2013 B1
8369960 Tran et al. Feb 2013 B2
8371501 Hopkins Feb 2013 B1
8381307 Cimino Feb 2013 B2
8391719 Alameh et al. Mar 2013 B2
8417231 Sanding et al. Apr 2013 B2
8439271 Smets et al. May 2013 B2
8475367 Yuen et al. Jul 2013 B1
8489112 Roeding et al. Jul 2013 B2
8511542 Pan Aug 2013 B2
8559872 Butler Oct 2013 B2
8566916 Vernon et al. Oct 2013 B1
8567670 Stanfield et al. Oct 2013 B2
8572386 Takekawa et al. Oct 2013 B2
8577810 Dalit et al. Nov 2013 B1
8583454 Beraja et al. Nov 2013 B2
8589335 Smith et al. Nov 2013 B2
8594730 Bona et al. Nov 2013 B2
8615468 Varadarajan Dec 2013 B2
8620218 Awad Dec 2013 B2
8667285 Coulier et al. Mar 2014 B2
8723941 Shirbabadi et al. May 2014 B1
8726405 Bailey et al. May 2014 B1
8740073 Shankar et al. Jun 2014 B2
8750514 Gallo et al. Jun 2014 B2
8752189 De Jong Jun 2014 B2
8794509 Bishop et al. Aug 2014 B2
8799668 Cheng Aug 2014 B2
8806592 Ganesan Aug 2014 B2
8807440 Von Behren et al. Aug 2014 B1
8811892 Khan et al. Aug 2014 B2
8814039 Bishop et al. Aug 2014 B2
8814052 Bona et al. Aug 2014 B2
8818867 Baldwin et al. Aug 2014 B2
8850538 Vernon et al. Sep 2014 B1
8861733 Benteo et al. Oct 2014 B2
8880027 Darringer Nov 2014 B1
8888002 Chesney et al. Nov 2014 B2
8898088 Springer et al. Nov 2014 B2
8934837 Zhu et al. Jan 2015 B2
8977569 Rao Mar 2015 B2
8994498 Agrafioti et al. Mar 2015 B2
9004365 Bona et al. Apr 2015 B2
9038894 Khalid May 2015 B2
9042814 Royston et al. May 2015 B2
9047531 Showering et al. Jun 2015 B2
9069976 Toole et al. Jun 2015 B2
9081948 Magne Jul 2015 B2
9104853 Venkataramani et al. Aug 2015 B2
9118663 Bailey et al. Aug 2015 B1
9122964 Krawczewicz Sep 2015 B2
9129280 Bona et al. Sep 2015 B2
9152832 Royston et al. Oct 2015 B2
9203800 Izu et al. Dec 2015 B2
9209867 Royston Dec 2015 B2
9251330 Boivie et al. Feb 2016 B2
9251518 Levin et al. Feb 2016 B2
9258715 Borghei Feb 2016 B2
9270337 Zhu et al. Feb 2016 B2
9306626 Hall et al. Apr 2016 B2
9306942 Bailey et al. Apr 2016 B1
9324066 Archer et al. Apr 2016 B2
9324067 Van OS et al. Apr 2016 B2
9332587 Salahshoor May 2016 B2
9338622 Bjontegard May 2016 B2
9373141 Shakkarwar Jun 2016 B1
9379841 Fine et al. Jun 2016 B2
9413430 Royston et al. Aug 2016 B2
9413768 Gregg et al. Aug 2016 B1
9420496 Indurkar Aug 2016 B1
9426132 Alikhani Aug 2016 B1
9432339 Bowness Aug 2016 B1
9455968 Machani et al. Sep 2016 B1
9473509 Arsanjani et al. Oct 2016 B2
9491626 Sharma et al. Nov 2016 B2
9553637 Yang et al. Jan 2017 B2
9619952 Zhao et al. Apr 2017 B1
9635000 Muftic Apr 2017 B1
9665858 Kumar May 2017 B1
9674705 Rose et al. Jun 2017 B2
9679286 Colnot et al. Jun 2017 B2
9680942 Dimmick Jun 2017 B2
9710804 Zhou et al. Jul 2017 B2
9740342 Paulsen et al. Aug 2017 B2
9740988 Levin et al. Aug 2017 B1
9763097 Robinson et al. Sep 2017 B2
9767329 Forster Sep 2017 B2
9769662 Queru Sep 2017 B1
9773151 Mil'shtein et al. Sep 2017 B2
9780953 Gaddam et al. Oct 2017 B2
9891823 Feng et al. Feb 2018 B2
9940571 Herrington Apr 2018 B1
9953323 Candelore et al. Apr 2018 B2
9961194 Wiechman et al. May 2018 B1
9965756 Davis et al. May 2018 B2
9965911 Wishne May 2018 B2
9978058 Wurmfeld et al. May 2018 B2
10043164 Dogin et al. Aug 2018 B2
10075437 Costigan et al. Sep 2018 B1
10129648 Hernandez et al. Nov 2018 B1
10133979 Eidam et al. Nov 2018 B1
10217105 Sangi et al. Feb 2019 B1
20010010723 Pinkas Aug 2001 A1
20010029485 Brody et al. Oct 2001 A1
20010034702 Mockett et al. Oct 2001 A1
20010054003 Chien et al. Dec 2001 A1
20020078345 Sandhu et al. Jun 2002 A1
20020093530 Krothapalli et al. Jul 2002 A1
20020100808 Norwood et al. Aug 2002 A1
20020120583 Keresman, III et al. Aug 2002 A1
20020152116 Yan et al. Oct 2002 A1
20020153424 Li Oct 2002 A1
20020165827 Gien et al. Nov 2002 A1
20030023554 Yap et al. Jan 2003 A1
20030034873 Chase et al. Feb 2003 A1
20030055727 Walker et al. Mar 2003 A1
20030078882 Sukeda et al. Apr 2003 A1
20030167350 Davis et al. Sep 2003 A1
20030208449 Diao Nov 2003 A1
20040015958 Veil et al. Jan 2004 A1
20040039919 Takayama et al. Feb 2004 A1
20040127256 Goldthwaite et al. Jul 2004 A1
20040215674 Odinak et al. Oct 2004 A1
20040230799 Davis Nov 2004 A1
20050044367 Gasparini et al. Feb 2005 A1
20050075985 Cartmell Apr 2005 A1
20050081038 Arditti Modiano et al. Apr 2005 A1
20050138387 Lam et al. Jun 2005 A1
20050156026 Ghosh et al. Jul 2005 A1
20050160049 Lundholm Jul 2005 A1
20050195975 Kawakita Sep 2005 A1
20050247797 Ramachandran Nov 2005 A1
20060006230 Bear et al. Jan 2006 A1
20060040726 Szrek et al. Feb 2006 A1
20060041402 Baker Feb 2006 A1
20060044153 Dawidowsky Mar 2006 A1
20060047954 Sachdeva et al. Mar 2006 A1
20060085848 Aissi et al. Apr 2006 A1
20060136334 Atkinson et al. Jun 2006 A1
20060173985 Moore Aug 2006 A1
20060174331 Schuetz Aug 2006 A1
20060242698 Inskeep et al. Oct 2006 A1
20060280338 Rabb Dec 2006 A1
20070033642 Ganesan et al. Feb 2007 A1
20070055630 Gauthier et al. Mar 2007 A1
20070061266 Moore et al. Mar 2007 A1
20070061487 Moore et al. Mar 2007 A1
20070116292 Kurita et al. May 2007 A1
20070118745 Buer May 2007 A1
20070197261 Humbel Aug 2007 A1
20070224969 Rao Sep 2007 A1
20070241182 Buer Oct 2007 A1
20070256134 Lehtonen et al. Nov 2007 A1
20070258594 Sandhu et al. Nov 2007 A1
20070278291 Rans et al. Dec 2007 A1
20080008315 Fontana et al. Jan 2008 A1
20080011831 Bonalle et al. Jan 2008 A1
20080014867 Finn Jan 2008 A1
20080035738 Mullen Feb 2008 A1
20080071681 Khalid Mar 2008 A1
20080072303 Syed Mar 2008 A1
20080086767 Kulkarni et al. Apr 2008 A1
20080103968 Bies et al. May 2008 A1
20080109309 Landau et al. May 2008 A1
20080110983 Ashfield May 2008 A1
20080120711 Dispensa May 2008 A1
20080156873 Wilhelm et al. Jul 2008 A1
20080162312 Sklovsky et al. Jul 2008 A1
20080164308 Aaron et al. Jul 2008 A1
20080207307 Cunningham, II et al. Aug 2008 A1
20080209543 Aaron Aug 2008 A1
20080223918 Williams et al. Sep 2008 A1
20080285746 Landrock et al. Nov 2008 A1
20080308641 Finn Dec 2008 A1
20090037275 Pollio Feb 2009 A1
20090048026 French Feb 2009 A1
20090132417 Scipioni et al. May 2009 A1
20090143104 Loh et al. Jun 2009 A1
20090171682 Dixon et al. Jul 2009 A1
20090210308 Toomer et al. Aug 2009 A1
20090235339 Mennes et al. Sep 2009 A1
20090249077 Gargaro et al. Oct 2009 A1
20090282264 Amiel et al. Nov 2009 A1
20100023449 Skowronek et al. Jan 2010 A1
20100023455 Dispensa et al. Jan 2010 A1
20100029202 Jolivet et al. Feb 2010 A1
20100033310 Narendra et al. Feb 2010 A1
20100036769 Winters et al. Feb 2010 A1
20100078471 Lin et al. Apr 2010 A1
20100082491 Rosenblatt et al. Apr 2010 A1
20100094754 Bertran et al. Apr 2010 A1
20100095130 Bertran et al. Apr 2010 A1
20100100480 Altman et al. Apr 2010 A1
20100114731 Kingston et al. May 2010 A1
20100192230 Steeves et al. Jul 2010 A1
20100207742 Buhot et al. Aug 2010 A1
20100211797 Westerveld et al. Aug 2010 A1
20100240413 He et al. Sep 2010 A1
20100257357 McClain Oct 2010 A1
20100312634 Cervenka Dec 2010 A1
20100312635 Cervenka Dec 2010 A1
20110028160 Roeding et al. Feb 2011 A1
20110035604 Habraken Feb 2011 A1
20110060631 Grossman et al. Mar 2011 A1
20110068170 Lehman Mar 2011 A1
20110084132 Tofighbakhsh Apr 2011 A1
20110101093 Ehrensvard May 2011 A1
20110113245 Varadrajan May 2011 A1
20110125638 Davis et al. May 2011 A1
20110131415 Schneider Jun 2011 A1
20110153437 Archer et al. Jun 2011 A1
20110153496 Royyuru Jun 2011 A1
20110208658 Makhotin Aug 2011 A1
20110208965 Machani Aug 2011 A1
20110211219 Bradley Sep 2011 A1
20110218911 Spodak Sep 2011 A1
20110238564 Lim et al. Sep 2011 A1
20110246780 Yeap et al. Oct 2011 A1
20110258452 Coulier et al. Oct 2011 A1
20110280406 Ma et al. Nov 2011 A1
20110282785 Chin Nov 2011 A1
20110294418 Chen Dec 2011 A1
20110312271 Ma et al. Dec 2011 A1
20120024947 Naelon Feb 2012 A1
20120030047 Fuentes et al. Feb 2012 A1
20120030121 Grellier Feb 2012 A1
20120047071 Mullen et al. Feb 2012 A1
20120079281 Lowenstein et al. Mar 2012 A1
20120109735 Krawczewicz et al. May 2012 A1
20120109764 Martin et al. May 2012 A1
20120143754 Patel Jun 2012 A1
20120150737 Rottink Jun 2012 A1
20120178366 Levy et al. Jul 2012 A1
20120196583 Kindo Aug 2012 A1
20120207305 Gallo et al. Aug 2012 A1
20120209773 Ranganathan Aug 2012 A1
20120238206 Singh et al. Sep 2012 A1
20120239560 Pourfallah et al. Sep 2012 A1
20120252350 Steinmetz et al. Oct 2012 A1
20120254394 Barras Oct 2012 A1
20120284194 Liu et al. Nov 2012 A1
20120290472 Mullen et al. Nov 2012 A1
20120296818 Nuzzi et al. Nov 2012 A1
20120316992 Oborne Dec 2012 A1
20120317035 Royyuru et al. Dec 2012 A1
20120317628 Yeager Dec 2012 A1
20130005245 Royston Jan 2013 A1
20130008956 Ashfield Jan 2013 A1
20130026229 Jarman et al. Jan 2013 A1
20130048713 Pan Feb 2013 A1
20130054474 Yeager Feb 2013 A1
20130065564 Conner et al. Mar 2013 A1
20130080228 Fisher Mar 2013 A1
20130080229 Fisher Mar 2013 A1
20130099587 Lou Apr 2013 A1
20130104251 Moore et al. Apr 2013 A1
20130106576 Hinman et al. May 2013 A1
20130119130 Braams May 2013 A1
20130130614 Busch-Sorensen May 2013 A1
20130144793 Royston Jun 2013 A1
20130171929 Adams et al. Jul 2013 A1
20130179351 Wallner Jul 2013 A1
20130185772 Jaudon et al. Jul 2013 A1
20130191279 Calman et al. Jul 2013 A1
20130200999 Spodak et al. Aug 2013 A1
20130216108 Hwang et al. Aug 2013 A1
20130226791 Springer et al. Aug 2013 A1
20130226796 Jiang et al. Aug 2013 A1
20130232082 Krawczewicz et al. Sep 2013 A1
20130238894 Ferg et al. Sep 2013 A1
20130282360 Shimota et al. Oct 2013 A1
20130303085 Boucher et al. Nov 2013 A1
20130304651 Smith Nov 2013 A1
20130312082 Izu et al. Nov 2013 A1
20130314593 Reznik et al. Nov 2013 A1
20130344857 Berionne et al. Dec 2013 A1
20140002238 Taveau et al. Jan 2014 A1
20140019352 Shrivastava Jan 2014 A1
20140027506 Heo et al. Jan 2014 A1
20140032409 Rosano Jan 2014 A1
20140032410 Georgiev et al. Jan 2014 A1
20140040120 Cho et al. Feb 2014 A1
20140040139 Brudnicki et al. Feb 2014 A1
20140040147 Varadarakan et al. Feb 2014 A1
20140047235 Lessiak et al. Feb 2014 A1
20140067690 Pitroda et al. Mar 2014 A1
20140074637 Hammad Mar 2014 A1
20140074655 Lim et al. Mar 2014 A1
20140081720 Wu Mar 2014 A1
20140138435 Khalid May 2014 A1
20140171034 Aleksin et al. Jun 2014 A1
20140171039 Bjontegard Jun 2014 A1
20140172700 Teuwen et al. Jun 2014 A1
20140180851 Fisher Jun 2014 A1
20140208112 McDonald et al. Jul 2014 A1
20140214674 Narula Jul 2014 A1
20140229375 Zaytzsev et al. Aug 2014 A1
20140245391 Adenuga Aug 2014 A1
20140256251 Caceres et al. Sep 2014 A1
20140258099 Rosano Sep 2014 A1
20140258113 Gauthier et al. Sep 2014 A1
20140258125 Gerber et al. Sep 2014 A1
20140274179 Zhu et al. Sep 2014 A1
20140279479 Maniar et al. Sep 2014 A1
20140298027 Roberts et al. Oct 2014 A1
20140337235 Van Heerden et al. Nov 2014 A1
20140339315 Ko Nov 2014 A1
20140346860 Aubry et al. Nov 2014 A1
20140365780 Movassaghi Dec 2014 A1
20140379361 Mahadkar et al. Dec 2014 A1
20150012444 Brown et al. Jan 2015 A1
20150032635 Guise Jan 2015 A1
20150071486 Rhoads et al. Mar 2015 A1
20150088757 Zhou et al. Mar 2015 A1
20150089586 Ballesteros Mar 2015 A1
20150134452 Williams May 2015 A1
20150140960 Powell et al. May 2015 A1
20150154595 Collinge et al. Jun 2015 A1
20150170138 Rao Jun 2015 A1
20150178724 Ngo et al. Jun 2015 A1
20150186871 Laracey Jul 2015 A1
20150205379 Mag et al. Jul 2015 A1
20150302409 Malek Oct 2015 A1
20150317626 Ran et al. Nov 2015 A1
20150332266 Friedlander et al. Nov 2015 A1
20150339474 Paz et al. Nov 2015 A1
20150371234 Huang et al. Dec 2015 A1
20160012465 Sharp Jan 2016 A1
20160026997 Tsui et al. Jan 2016 A1
20160048913 Rausaria et al. Feb 2016 A1
20160055480 Shah Feb 2016 A1
20160057619 Lopez Feb 2016 A1
20160065370 Le Saint et al. Mar 2016 A1
20160087957 Shah et al. Mar 2016 A1
20160092696 Guglani et al. Mar 2016 A1
20160148193 Kelley et al. May 2016 A1
20160232523 Venot et al. Aug 2016 A1
20160239672 Khan et al. Aug 2016 A1
20160253651 Park et al. Sep 2016 A1
20160255072 Liu Sep 2016 A1
20160267486 Mitra et al. Sep 2016 A1
20160277383 Guyomarc'h et al. Sep 2016 A1
20160277388 Lowe et al. Sep 2016 A1
20160295404 Gouget Oct 2016 A1
20160307187 Guo et al. Oct 2016 A1
20160307189 Zarakas et al. Oct 2016 A1
20160314472 Ashfield Oct 2016 A1
20160330027 Ebrahimi Nov 2016 A1
20160335531 Mullen et al. Nov 2016 A1
20160379217 Hammad Dec 2016 A1
20170004502 Quentin et al. Jan 2017 A1
20170011395 Pillai et al. Jan 2017 A1
20170011406 Tunnell et al. Jan 2017 A1
20170017957 Radu Jan 2017 A1
20170017964 Janefalkar et al. Jan 2017 A1
20170024716 Jiam et al. Jan 2017 A1
20170039566 Schipperheijn Feb 2017 A1
20170041759 Gantert et al. Feb 2017 A1
20170068950 Kwon Mar 2017 A1
20170103388 Pillai et al. Apr 2017 A1
20170104739 Lansler et al. Apr 2017 A1
20170109509 Baghdasaryan Apr 2017 A1
20170109730 Locke et al. Apr 2017 A1
20170116447 Cimino et al. Apr 2017 A1
20170124568 Moghadam May 2017 A1
20170140379 Deck May 2017 A1
20170154328 Zarakas et al. Jun 2017 A1
20170154333 Gleeson et al. Jun 2017 A1
20170180134 King Jun 2017 A1
20170230189 Toll et al. Aug 2017 A1
20170237301 Elad et al. Aug 2017 A1
20170289127 Hendrick Oct 2017 A1
20170295013 Claes Oct 2017 A1
20170316696 Bartel Nov 2017 A1
20170317834 Smith et al. Nov 2017 A1
20170330173 Woo et al. Nov 2017 A1
20170374070 Shah et al. Dec 2017 A1
20180034507 Wobak et al. Feb 2018 A1
20180039986 Essebag et al. Feb 2018 A1
20180068316 Essebag et al. Mar 2018 A1
20180129945 Saxena et al. May 2018 A1
20180160255 Park Jun 2018 A1
20180191501 Lindemann Jul 2018 A1
20180205712 Versteeg et al. Jul 2018 A1
20180240106 Garrett et al. Aug 2018 A1
20180254909 Hancock Sep 2018 A1
20180268132 Buer et al. Sep 2018 A1
20180270214 Caterino et al. Sep 2018 A1
20180294959 Traynor et al. Oct 2018 A1
20180300716 Carlson Oct 2018 A1
20180302226 Heimlicher Oct 2018 A1
20180302396 Camenisch et al. Oct 2018 A1
20180315050 Hammad Nov 2018 A1
20180316666 Koved et al. Nov 2018 A1
20180322486 Deliwala et al. Nov 2018 A1
20180359100 Gaddam et al. Dec 2018 A1
20190014107 George Jan 2019 A1
20190019375 Foley Jan 2019 A1
20190036678 Ahmed Jan 2019 A1
20190238517 D'Agostino et al. Aug 2019 A1
20200104841 Osborn Apr 2020 A1
20210209606 Herlands Jul 2021 A1
20220237281 Best Jul 2022 A1
20220284178 Rule Sep 2022 A1
Foreign Referenced Citations (38)
Number Date Country
3010336 Jul 2017 CA
101192295 Jun 2008 CN
103023643 Apr 2013 CN
103417202 Dec 2013 CN
1 085 424 Mar 2001 EP
1 223 565 Jul 2002 EP
1 265 186 Dec 2002 EP
1 783 919 May 2007 EP
2 852 070 Jan 2009 EP
2 139 196 Dec 2009 EP
1 469 419 Feb 2012 EP
2 457 221 Aug 2009 GB
2 516 861 Feb 2015 GB
2 551 907 Jan 2018 GB
101508320 Apr 2015 KR
WO 0049586 Aug 2000 WO
WO 2006070189 Jul 2006 WO
WO 2008055170 May 2008 WO
WO 2009025605 Feb 2009 WO
WO 2010049252 May 2010 WO
WO 2011112158 Sep 2011 WO
WO 2012001624 Jan 2012 WO
WO 2013039395 Mar 2013 WO
WO 2013155562 Oct 2013 WO
WO 2013192358 Dec 2013 WO
WO 2014043278 Mar 2014 WO
WO 2014170741 Oct 2014 WO
WO 2015179649 Nov 2015 WO
WO 2015183818 Dec 2015 WO
WO 2016097718 Jun 2016 WO
WO 2016160816 Oct 2016 WO
WO 2016168394 Oct 2016 WO
WO 2017042375 Mar 2017 WO
WO 2017042400 Mar 2017 WO
WO 2017157859 Sep 2017 WO
WO 2017208063 Dec 2017 WO
WO 2018063809 Apr 2018 WO
WO 2018137888 Aug 2018 WO
Non-Patent Literature Citations (42)
Entry
Batina, Lejla and Poll, Erik, “SmartCards and RFID,” PowerPoint Presentation for IPA Security Course, Digital Security at University of Nijmegen, Netherlands (date unknown), 75 pages.
Haykin M. and Warnar, R., “Smart Card Technology: New Methods for Computer Access Control,” Computer Science and Technology NIST Special Publication 500-157:1-60 (1988).
Lehpamer, Harvey, “Component of the RFID System,” RFID Design Principles, 2nd edition pp. 133-201 (2012).
Pourghomi, Pardis et al., “A Proposed NFC Payment Application,” International Journal of Advanced Computer Science and Applications, vol. 4, No. 8 (2013).
Author Unknown, “CardrefresherSM from American Express®,” [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://merchant-channel.americanexpress.com/merchant/en_US/cardrefresher, 2 pages.
Author Unknown, “Add Account Updater to your recurring payment tool,” [online] 2018-19 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.authorize.net/our-features/account-updater/, 5 pages.
Author Unknown, “Visa® Account Updater for Merchants,” [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://usa.visa.com/dam/VCOM/download/merchants/visa-account-updater-product-information-fact-sheet-for-merchants.pdf, 2 pages.
Author Unknown, “Manage the cards that you use with Apple Pay,” Apple Support [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.apple.com/en-us/HT205583, 5 pages.
Author Unknown, “Contactless Specifications for Payment Systems,” EMV Book B—Entry Point Specification [online] 2016 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.emvco.com/wp-content/uploads/2017/05/BookB_Entry_Point_Specification_v2_6_20160809023257319.pdf, 52 pages.
Author Unknown, “EMV Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management,” Version 3.4, [online] 2011 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.emvco.com/wp-content/uploads/2017/05/EMV_v4.3_Book_2_Security_and_Key_Management_20120607061923900.pdf, 174 pages.
Author unknown, “NFC Guide: All You Need to Know About Near Field Communication” Square Guide [online] 2018[retrieved on Nov. 13, 2018]. Retrieved from Internet URL: https://squareup.com/guides/nfc, 8 pages.
Profis, S., “Everything you need to know about NFC and mobile payments” CNET Directory [online], 2014 [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://www.cnet.com/how-to/how-nfc-works-and-mobile-payments/, 6 pages.
Cozma, N., “Copy data from other devices in Android 5.0 Lollipop setup” CNET Directory [online] 2014 [retrieved on Mar. 19, 2025]. Retrieved from the Internet URL: https://www.cnet.com/how-to/copy-data-from-other-devices-in-android-5-0-lollipop-setup/, 5 pages.
Kevin, Android Enthusiast, “How to copy text string from nfc tag” StackExchange [online] 2013 [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://android.stackexchange.com/questions/55689/how-to-copy-text-string-from-nfc-tag, 11 pages.
Author unknown, “Tap & Go Device Setup” Samsung [online] date unknown [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://www.samsung.com/us/switch-me/switch-to-the-galaxy-s-5/app/partial/setup-device/tap-go.html, 1 page.
Author Unknown, “Multiple encryption”, Wikipedia [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://en.wikipedia.org/wiki/Multiple_encryption, 4 pages.
Krawczyk, et al., “HMAC: Keyed-Hashing for Message Authentication”, Network Working Group RFC:2104 memo [online] 1997 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://tools.ietf.org/html/rfc2104, 12 pages.
Song, et al., “The AES-CMAC Algorithm”, Network Working Group RFC: 4493 memo [online] 2006 [retrieved on Ma. 25, 2019]. Retrieved from Internet URL: https://tools.ietf.org/html/rfc4493, 21 pages.
Katz, J., and Lindell, Y., “Aggregate Message Authentication Codes”, Topics in Cryptology [online] 2008 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.cs.umd.edu/˜jkatz/papers/aggregateMAC.pdf, 11 pages.
Adams, D., and Maier, A-K, “Goldbug Big Seven open source crypto-messengers to be compared- : or Comprehensive Confidentiality Review & Audit of GoldBug Encrypting E-Mail-Client & Secure Instant Messenger”, Big Seven Study 2016 [online] [retrieved on Mar. 25, 2018]. Retrieved from Internet URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf, 309 pages.
Author Unknown, “Triple DES”, Wikipedia [online] 2018 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://simple.wikipedia.org/wiki/Triple_DES, 2 pages.
Song, F., and Yun, A.1, “Quantum Security of NMAC and Related Constructions—PRF domain extension against quantum attacks”, IACR Cryptology ePrint Archive [online] 2017 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://eprint.iacr.org/2017/509.pdf, 41 pages.
Saxena, N., “Lecture 10: NMAC, HMAC and Number Theory”, CS 6903 Modern Cryptography [online] 2008 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: http://isis.poly.edu/courses/cs6903/Lectures/lecture10.pdf, 8 pages.
Berg, Guy, “Fundamentals of EMV” Smart Card Alliance [online] date unknown [retrieved on Mar. 27, 2019]. Retrieved from Internet URL: https://www.securetechalliance.org/resources/media/scap13_preconference/02.pdf, 37 pages.
Pierce, Kevin, “Is the amazon echo NFC compatible,?” Amazon.com Customer Q&A [online] 2016 [retrieved on Mar. 26, 2019]. Retrieved from Internet URL: https://www.amazon.com/ask/questions/Tx1RJXYSPE6XLJD?_encodi . . . , 2 pages.
Author Unknown, “Multi-Factor Authentication”, idaptive [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.centrify.com/products/application-services/adaptive-multi-factor-authentication/risk-based-mfa/, 10 pages.
Author Unknown, “Adaptive Authentication”, SecureAuth [online] 2019 [retrieved on Mar. 25, 2019}. Retrieved from Internet URL: https://www.secureauth.com/products/access-management/adaptive-authentication, 7 pages.
Van den Breekel, J., et al., “EMV in a nutshell”, Technical Report, 2016 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.cs.ru.nl/E.Poll/papers/EMVtechreport.pdf, 37 pages.
Author Unknown, “Autofill”, Computer Hope [online] 2018 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.computerhope.com/jargon/a/autofill.htm, 2 pages.
Author Unknown, “Fill out forms automatically”, Google Chrome Help [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.google.com/chrome/answer/142893?co=GENIE.Platform%3DDesktop&hl=en, 3 pages.
Author unknown, “Autofill credit cards, contacts, and passwords in Safari on Mac”, Apple Safari User Guide [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.apple.com/guide/safari/use-autofill-ibrw1103/mac, 3 pages.
Menghin, M.J., “Power Optimization Techniques for Near Field Communication Systems” 2014 Dissertation at Technical University of Graz [online]. Retrieved from Internet URL: https://diglib.tugraz.at/download.php?id=576a7b910d2d6&location=browse, 135 pages.
Mareli, M., et al., “Experimental evaluation of NFC reliability between an RFID tag and a smartphone” Conference paper (2013) IEEE Africon at Mauritius [online] [retrieved on Mra. 25, 2019]. Retrieved from Internet URL: https://core.ac.uk/download/pdf/54204839.pdf, 5 pages.
Davison, A., et al., “MonoSLAM: Real-Time Single Camera SLAM”, IEEE Transactions on Pattern Analysis and Machine Intelligence 29(6): 1052-1067 (2007).
Barba, R., “Sharing your location with your bank sounds creepy, but it's also useful”, Bankrate, LLC [online] 2017 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.bankrate.com/banking/banking-app-location-sharing/, 6 pages.
Author unknown: “onetappayment™”, [online] Jan. 24, 2019, [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.payubiz.in/onetap, 4 pages.
Vu et al., (2012). “Distinguishing users with capacitive touch communication” Proceedings of the Annual International Conference on Mobile Computing and Networking, Mobicom. 10.1145/2348543.2348569.
EMVCo, EMV Card Personalization Specification, version 1.0 (Jun. 2003), 81 pages.
Ullmann et al., (2012). “On-Card” User Authentication for Contactless Smart Cards based on Gesture Recognition, LNI, 223-234, 12 pages.
Faraj et al. (2008). “Investigation of Java Smart Card Technology for Multi-Task Applications” J. of Al-Anbar University for Pure Science, vol. 2: No. 1: 2008, 11 pages.
Dhamdhere (2017) “Key Benefits of a Unified Platform for Loyalty, Referral Marketing, and UGC” Annex Cloud [retrieved on Jul. 3, 2019]. Retrieved from Internet URL: https://www.annexcloude.com/blog/benefits-unified-platform/, 13 pages.
International Search Report and the Written Opinion of the International Searching Authority issued in related PCT Application No. PCT/US2022/033729 mailed Sep. 28, 2022, 15 pages.
Related Publications (1)
Number Date Country
20220407724 A1 Dec 2022 US