Systems and methods for increasing security for digital transactions with predetermined risk factors

Abstract

Systems and methods disclosed herein may determine when a digital transaction initiated in association with a user account satisfies at least one predetermined risk factor. In response to this, the systems and methods disclosed herein may improve security prior to performing a digital transaction associated with a user account to verify that the digital transaction may be initiated by an authorized user of the user account. To this end, the mobile device may communicate with the contactless card to receive a ciphertext therefrom, validate the ciphertext to identify the user account and confirm that the contactless card is associated with the user account, and validate that the phone number of the mobile device is also associated with the user account.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480045212.3 (22) Application Date 2024.07.31 (30) Priority Data 18 / 232,541 2023.08.10 US (85) PCT International Application Entering National Phase Date 2025.12.31 (86) PCT International Application Application Data PCT / US2024 / 040305 2024.07.31 (87) PCT International Application Publication Data WO2025 / 034479 EN 2025.02.13 (71) Applicant: Capital One Services LLC Address: USA (72) Inventor: Daniel Pikjayant Pratipatico Hart (74) Patent Agency: Beijing Pinyuan Patent Agency Co., Ltd. 11332 Patent Attorneys Tan Yingying and Hu Bin (51) Int.Cl. G06Q 20 / 32 (2006.01) G06Q 20 / 34 (2006.01) G06Q 20 / 38 (2006.01) G06Q 20 / 40 (2006.01) G06Q 20 / 42 (2006.01) (54) Title of Invention System and Method for Improving the Security of Digital Transactions with Predetermined Risk Factors (57) Abstract The system and method disclosed herein can determine when a digital transaction initiated in connection with a user account meets at least one predetermined risk factor. In response, the system and method disclosed herein can improve security before executing a digital transaction associated with a user account by verifying that the digital transaction may have been initiated by an authorized user of the user account. To this end, the mobile device can communicate with a contactless card to receive ciphertext therefrom, verify the ciphertext to identify the user account and confirm that the contactless card is associated with the user account, and verify that the mobile device's telephone number is also associated with the user account. Claims 2 pages, Description 26 pages, Drawings 15 pages, CN 121444116 A 2026.01.30 CN 1 21 44 41 16 A 1. A method comprising: requesting communication between a contactless card and a mobile device when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor; receiving ciphertext from the contactless card via a short-range communication antenna of the mobile device; verifying the ciphertext via a processor of the mobile device to identify the user account and confirm that the contactless card is associated with the user account; verifying via the processor of the mobile device that a telephone number of the mobile device is associated with the user account; and authorizing the execution of a digital transaction associated with the user account when both the contactless card and the telephone number of the mobile device are associated with the user account.2. The method of claim 1, wherein the digital transaction includes wire transfer. 3. The method of claim 1, wherein the at least one predetermined risk factor includes the value of the digital transaction reaching or exceeding a predetermined monetary amount. 4. The method of claim 1, wherein the at least one predetermined risk factor includes digital transactions originating from suspicious locations, suspicious devices, or suspicious Internet Protocol (IP) addresses. 5. The method of claim 1, further comprising: successfully decrypting the ciphertext to verify the ciphertext and identify the user account. 6. The method of claim 5, further comprising: decrypting protected data in the ciphertext; comparing the protected data with stored record data associated with the contactless card; and identifying the user account based on the match between the protected data and the stored record data. 7. The method of claim 1, further comprising: transmitting the ciphertext from the mobile device to a server; and receiving at the mobile device one or more indications that the ciphertext and the mobile device's phone number have been verified. 8. The method of claim 7, further comprising: transmitting one or more messages from the mobile device to the server. 9. A non-transitory computer-readable storage medium storing instructions, which, when executed by a processor, cause the processor to perform the following operations: requesting communication between a contactless card and a mobile device when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor; receiving ciphertext from the contactless card via a short-range communication antenna of the mobile device; verifying the ciphertext to identify the user account and confirm that the contactless card is associated with the user account; verifying that a telephone number of the mobile device is associated with the user account; and authorizing the execution of a digital transaction associated with the user account when both the contactless card and the telephone number of the mobile device are associated with the user account. 10. The non-transitory computer-readable medium of claim 9, wherein the digital transaction includes a wire transfer. 11. The non-transitory computer-readable medium of claim 9, wherein the at least one predetermined risk factor includes the value of the digital transaction reaching or exceeding a predetermined monetary amount. Claims 1 / 2 Page 2 CN 121444116 A 12. The non-transitory computer-readable medium of claim 9, wherein the at least one predetermined risk factor includes digital transactions originating from a suspicious location, a suspicious device, or a suspicious IP address. 13. The non-transitory computer-readable medium of claim 9, wherein the instructions further cause the processor to successfully decrypt the ciphertext to verify the ciphertext and identify the user account.14. The non-transitory computer-readable medium of claim 13, wherein the instructions cause the processor to further perform the following operations: decrypt protected data in the ciphertext; compare the protected data with stored record data associated with the contactless card; and identify the user account based on the match between the protected data and the stored record data. 15. The non-transitory computer-readable medium of claim 13, wherein the instructions cause the processor to further perform the following operations: transmit the ciphertext to a server; and receive one or more indications that the ciphertext and the mobile device's telephone number have been verified. 16. The non-transitory computer-readable medium of claim 15, wherein the instructions further cause the processor to transmit one or more messages to the server. 17. A mobile device, the mobile device comprising: a short-range communication antenna; a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform the following operations: requesting communication with a contactless card when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor; receiving ciphertext from the contactless card via the short-range communication antenna; verifying the ciphertext to identify the user account and confirm that the contactless card is associated with the user account; verifying that a telephone number of the mobile device is associated with the user account; and authorizing the execution of a digital transaction associated with the user account when both the contactless card and the telephone number of the mobile device are associated with the user account. 18. The mobile device of claim 17, further comprising: a user interface device, wherein the instructions further cause the processor to display or issue a request for communication with the contactless card on the user interface device. 19. The mobile device of claim 17, further comprising: an internet browser or a mobile application, wherein the digital transaction is initiated via the internet browser or the mobile application. 20. The mobile device of claim 17, wherein the digital transaction is initiated via an internet browser on a desktop computer. Claims 2 / 2 Page 3 CN 121444116 A Systems and methods for improving the security of digital transactions with predetermined risk factors Cross-Reference to Related Applications

[0001] This application claims priority to U.S. Patent Application Serial No. 18 / 232,541, filed August 10, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0002] Customers typically initiate digital transactions, such as wire transfers, from internet browsers on desktop computers or mobile devices and from mobile applications on mobile devices.Some security measures (such as usernames and passwords) are routinely implemented to ensure that only authorized users can initiate these digital transactions. However, some digital transactions are inherently high-risk, prone to fraud, or associated with bad actors. Summary of the Invention

[0003] In some embodiments, a method may include: requesting communication between a contactless card and a mobile device when a digital transaction initiated with respect to a user account meets at least one predetermined risk factor; receiving ciphertext from the contactless card via a short-range communication antenna of the mobile device; verifying the ciphertext via a processor of the mobile device to identify the user account and confirm that the contactless card is associated with the user account; verifying that the mobile device's telephone number is associated with the user account via a processor of the mobile device; and authorizing the execution of the digital transaction associated with the user account when both the contactless card and the mobile device's telephone number are associated with the user account.

[0004] In some embodiments, the digital transaction may include a wire transfer. In some embodiments, at least one predetermined risk factor may include the value of the digital transaction reaching or exceeding a predetermined monetary amount. In some embodiments, at least one predetermined risk factor may include a digital transaction originating from a suspicious location, a suspicious device, or a suspicious Internet Protocol (IP) address.

[0005] In some embodiments, the method may include successfully decrypting the ciphertext to verify the ciphertext and identify the user account. In some embodiments, the method may include decrypting protected data in ciphertext, comparing the protected data with stored record data associated with the contactless card, and identifying a user account based on the match between the protected data and the stored record data.

[0006] In some embodiments, the method may include transmitting ciphertext from a mobile device to a server and receiving one or more indications at the mobile device that the ciphertext and the mobile device's phone number have been verified. In some embodiments, the method may include transmitting one or more messages from the mobile device to the server.

[0007] In some embodiments, a non-transitory computer-readable medium may include instructions that, when executed by a processor, cause the processor to: request communication between the contactless card and the mobile device when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor; receive ciphertext from the contactless card via a short-range communication antenna of the mobile device; verify the ciphertext to identify the user account and confirm that the contactless card is associated with the user account; verify that the mobile device's phone number is associated with the user account; and authorize the execution of the digital transaction associated with the user account when both the contactless card and the mobile device's phone number are associated with the user account.

[0008] In some embodiments, the digital transaction may include a wire transfer. In some embodiments, at least one predetermined risk factor may include the value of the digital transaction reaching or exceeding a predetermined monetary amount.In some embodiments, at least one predetermined risk factor may include digital transactions originating from a suspicious location, a suspicious device, or a suspicious IP address.

[0009] In some embodiments, the instructions may also cause the processor to successfully decrypt the ciphertext to verify the ciphertext and identify a user account. In some embodiments, the instructions may also cause the processor to perform the following operations: decrypt protected data in the ciphertext, compare the protected data with stored record data associated with a contactless card, and identify a user account based on the match between the protected data and the stored record data.

[0010] In some embodiments, the instructions may also cause the processor to perform the following operations: transmit the ciphertext to a server, and receive one or more indications that the ciphertext and the mobile device's phone number have been verified. In some embodiments, the instructions may also cause the processor to transmit one or more messages to the server.

[0011] In some embodiments, the mobile device may include a short-range communication antenna, a processor, and a memory storing instructions that, when executed by the processor, cause the processor to perform the following operations: request communication with a contactless card when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor; receive ciphertext from the contactless card via the short-range communication antenna; verify the ciphertext to identify the user account and confirm that the contactless card is associated with the user account; verify that the mobile device's phone number is associated with the user account; and authorize the execution of the digital transaction associated with the user account when both the contactless card and the mobile device's phone number are associated with the user account.

[0012] In some embodiments, the mobile device may include a user interface device, and the instructions may also cause the processor to display or issue a request for communication with the contactless card on the user interface device.

[0013] In some embodiments, the mobile device may include an internet browser or a mobile application, and the digital transaction may be initiated via an internet browser or mobile application.

[0014] In some embodiments, the digital transaction may be initiated via an internet browser on a desktop computer.

[0015] Other technical features will be apparent to those skilled in the art from the following figures, description, and claims.

[0016] FIG1 illustrates an example of a system according to one embodiment.

[0017] FIG2 illustrates an example of a system according to one embodiment.

[0018] FIG3 illustrates an example of a contactless card according to one embodiment.

[0019] FIG4 illustrates an example of a transaction card component according to one embodiment.

[0020] FIG5 illustrates an example of a sequence flow according to one embodiment.

[0021] FIG6 illustrates an example of a data structure according to one embodiment.

[0022] FIG7 illustrates an example of a key system according to one embodiment.

[0023] FIG8 illustrates an example of a method for generating ciphertext according to one embodiment.

[0024] FIG9 illustrates an example of a key distribution method according to one embodiment.

[0025] FIG10 illustrates an example of a card activation method according to one embodiment.

[0026] FIG11 illustrates an example of a mobile device according to one embodiment.

[0027] FIG12 illustrates an example of a system according to one embodiment.

[0028] FIG13 illustrates an example of a method according to one embodiment.

[0029] FIG14 illustrates an example of a sequence flow according to one embodiment.

[0030] FIG15 illustrates an example of a computer architecture according to one embodiment.

[0031] FIG16 illustrates an example of a communication architecture according to one embodiment. Specification 2 / 26 pages 5 CN 121444116 A Detailed Description

[0032] The embodiments disclosed herein generally relate to systems and methods for improving the security of digital transactions with predetermined risk factors. For example, in some embodiments, the systems and methods disclosed herein can determine when a digital transaction initiated with respect to a user account meets at least one predetermined risk factor. In these cases, the systems and methods disclosed herein do not simply execute digital transactions, but rather enhance security before executing digital transactions associated with a user account by verifying that the digital transaction may be initiated by an authorized user of the user account.

[0033] It should be understood that digital transactions can include any transaction that can occur without cash or paper from beginning to end. For example, in some embodiments, digital transactions can include wire transfers. Additionally or alternatively, digital transfers can include any exchange of goods or services, whether electronic (such as the Internet) or face-to-face. Additionally or alternatively, in some embodiments, digital transactions can include access to secure items or locations (e.g., lockboxes, safes, or restricted areas). In any embodiment, digital transactions can include any type of exchange or interaction that requires a sliding security scale.

[0034] In some embodiments, at least one predetermined risk factor can include the value of the digital transaction reaching or exceeding a predetermined monetary amount. Additionally or alternatively, in some embodiments, at least one predetermined risk factor can include digital transactions originating from suspicious locations (such as within or outside a designated country). Additionally or alternatively, in some embodiments, at least one predetermined risk factor may include digital transactions originating from suspicious devices or suspicious IP addresses (such as unknown devices or IP addresses), or devices or IPs known to lead to fraud.

[0035] In any embodiment, the systems and methods disclosed herein may request communication between a contactless card and a mobile device when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor.Then, the mobile device's short-range communication antenna can receive ciphertext from the contactless card, and the mobile device's processor can verify the ciphertext to identify the user account and confirm that the contactless card is associated with the user account. In some embodiments, the mobile device's processor can also verify whether the mobile device's phone number is associated with the user account. When both conditions are met, i.e., the contactless card and the mobile device's phone number are both confirmed and verified to be associated with the user account, the systems and methods disclosed herein can authorize the execution of digital transactions associated with the user account.

[0036] In some embodiments, the mobile device's processor can successfully decrypt the ciphertext to verify the ciphertext and identify the user account. For example, in some embodiments, the mobile device's processor can decrypt protected data in the ciphertext, compare the protected data with record data stored in a database for the user account, and identify the user account based on the match between the protected data and the stored record data.

[0037] Additionally or alternatively, in some embodiments, the mobile device can transmit one or more messages including ciphertext to a server communicating with the mobile device, and the server can successfully decrypt the ciphertext to verify the ciphertext and identify the user account. The server can also verify whether the mobile device's phone number is associated with the user account. Therefore, the mobile device can receive one or more indication messages from the server indicating that the ciphertext and / or the mobile device's phone number has been verified.

[0038] Advantageously, the systems and methods disclosed herein can provide enhanced security for certain digital transactions. In fact, when a digital transaction is identified as inherently risky due to meeting one or more risk factors, the systems and methods disclosed herein can verify that the digital transaction may have been initiated by an authorized user of the user account. In this regard, any digital transaction initiated by a bad actor and associated with the user account will not be executed unless the bad actor possesses a contactless card associated with the user account. Furthermore, even if the bad actor possesses a contactless card associated with the user account, the digital transaction will still not be executed unless the bad actor also possesses a mobile device with a phone number associated with the user account, which is impossible.

[0039] Details of the above embodiments and their additional advantages are discussed in the following description. Specification 3 / 26 pages 6 CN 121444116 A

[0040] FIG1 illustrates a data transmission system 100 according to an example embodiment. As discussed further below, system 100 may include contactless card 102, client device 104, network 106, and server 108. Although Figure 1 shows a single example of the components, system 100 may include any number of components.

[0041] System 100 may include one or more contactless cards 102, which will be explained further below.In some embodiments, the contactless card 102 can wirelessly communicate with the client device 104, for example using near field communication (NFC).

[0042] System 100 may include client device 104, which may be a network-enabled computer. As described herein, a network-enabled computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, networked appliances, personal computers, workstations, telephones, handheld personal computers (PCs), personal digital assistants, thin clients, fat clients, internet browsers, or other devices. Client device 104 may also be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system from Apple®, a device running Microsoft's Windows® mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0043] Client device 104 may include a processor and memory, and it should be understood that the processing circuitry may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / cyclic redundancy check (CRC) checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware. Client device 104 may also include display devices and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any device available to and supported by the user equipment for inputting information into the user equipment, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0044] In some examples, client device 104 of system 100 may execute one or more applications, such as software applications, which, for example, are capable of network communication with one or more components of system 100 and transmitting and / or receiving data.

[0045] Client device 104 may communicate with one or more servers 108 via one or more networks 106 and may operate as a corresponding front-end / back-end paired with server 108. Client device 104 may, for example, transmit one or more requests to server 108 from a mobile application running on client device 104. One or more requests may be associated with retrieving data from server 108. Server 108 may receive one or more requests from client device 104.Based on one or more requests from client device 104, server 108 can be configured to retrieve requested data from one or more databases (not shown). Based on receiving the requested data from one or more databases, server 108 can be configured to transmit the received data to client device 104 in response to one or more requests.

[0046] System 100 may include one or more networks 106. In some examples, network 106 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 104 to server 108. For example, network 106 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiple access based system, code division multiple access based system, digital advanced mobile phone system (D-AMPS), Wi-Fi, fixed wireless data, IEEE 802.11 series networking, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi and / or similar networks.

[0047] In addition, network 106 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 802.3, wide area network, wireless personal area network, LAN or global network such as the Internet. In addition, network 106 may support the Internet, wireless communication network, cellular network or similar network, or any combination thereof. Network 106 may also include a network, or any number of exemplary types of networks described above, operating as independent networks or collaborating with each other. Network 106 may utilize one or more protocols coupled to one or more network elements. Network 106 may be converted from other protocols to one or more protocols of network devices, or vice versa. Although network 106 is depicted as a single network, it should be understood that, according to one or more examples, network 106 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

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

[0049] FIG2 illustrates a data transmission system according to an example embodiment. System 200 may include, for example, a transmitting or sending device 204 and a receiving or receiving device 208 communicating with one or more servers 202 via network 206. Transmitting or sending device 204 may be the same as or similar to client device 104 discussed above with reference to FIG1. ​​Receiving or receiving device 208 may be the same as or similar to client device 104 discussed above with reference to FIG1. ​​Network 206 may be similar to network 106 discussed above with reference to FIG1. ​​Server 202 may be similar to server 108 discussed above with reference to FIG1. ​​Although FIG2 shows a single instance of the components of system 200, system 200 may include any number of illustrated components.

[0050] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cryptographic message authentication code (CMAC) algorithms, it is important that the key remains confidential between the party that initially processes the protected data using the symmetric algorithm and key and the other party that receives and processes the data using the same cryptographic algorithm and the same key.

[0051] Equally important, the same key should not be used multiple times. If a key is used frequently or repeatedly, it may be compromised. Each time the key is used, it provides an attacker with additional data samples processed by the cryptographic algorithm using the same key. The more data an attacker processes using the same key, the greater the likelihood that the attacker will discover the key value. Frequently used keys can be included in a variety of different attacks.

[0052] Furthermore, each time a symmetric cryptographic algorithm is executed, it may expose information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data can include tiny power fluctuations that occur while the cryptographic algorithm is being executed using the key. Enough measurements of the side-channel data can be taken to expose enough information about the key to allow an attacker to recover the key. Exchanging data using the same key repeatedly exposes data processed by the same key.

[0053] However, by limiting the number of times a particular key is used, the amount of side-channel data that an attacker can collect is limited, and thus the risk of suffering such and other types of attacks is reduced. As further described herein, the parties involved in exchanging encrypted information (e.g., the sender and the receiver) can independently generate keys based on an initial shared master symmetric key combined with a counter value, and thus periodically replace the shared symmetric key being used without any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and the receiver, the aforementioned attacks become impossible.

[0054] Referring back to Figure 2, system 200 can be configured to implement key distribution. For example, the sender and the receiver may wish to exchange data (e.g., raw sensitive data) via their respective devices 204 and 208.As described above, while individual instances of transmitting device 204 and receiving device 208 may be included, it is understood that one or more transmitting devices 204 and one or more receiving devices 208 can be involved as long as the parties share the same shared secret symmetric key. In some examples, transmitting device 204 and receiving device 208 may be equipped with the same master symmetric key. Furthermore, it should be understood that any party or device holding the same secret symmetric key can perform the functions of transmitting device 204, and similarly, any party holding the same secret symmetric key can perform the functions of receiving device 208. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties except for transmitting device 204 and receiving device 208 involved in exchanging secure data. It is also understood that transmitting device 204 and receiving device 208 may be set with the same master symmetric key, and further, a portion of the data exchanged between transmitting device 204 and receiving device 208 includes at least a portion of data that can be referred to as a counter value. The counter value may include a number that changes each time data is exchanged between the transmitting device 204 and the receiving device 208.

[0055] System 200 may include one or more networks 206. In some examples, network 206 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect one or more transmitting device devices 204 and one or more receiving devices 208 to server 202. For example, network 206 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless LAN, Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiple access based system, code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11 series networking, Bluetooth, NFC, RFID, Wi-Fi and / or similar networks.

[0056] Additionally, network 206 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Furthermore, network 206 may support Internet networks, wireless communication networks, cellular networks, etc., or any combination thereof. Network 206 may also include a network or any number of the aforementioned exemplary network types operating independently or collaboratively with each other. Network 206 may utilize one or more protocols coupled to one or more network elements. Network 206 may convert from other protocols to one or more protocols of network devices, or vice versa.Although network 206 is depicted as a single network, it should be understood that, according to one or more examples, network 206 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

[0057] In some examples, one or more transmitting devices 204 and one or more receiving devices 208 may be configured to communicate with each other and to transmit and receive data without passing through network 206. For example, communication between one or more transmitting devices 204 and one or more receiving devices 208 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and / or similar technologies.

[0058] At block 210, when transmitting device 204 is ready to process sensitive data using symmetric cryptographic operations, the sender may update a counter. Additionally, transmitting device 204 may select an appropriate symmetric cryptographic algorithm, which may include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process scatter values ​​may include any symmetric cryptographic algorithm used to generate a scatter symmetric key of the desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or Advanced Encryption Standard 128 (AES128); symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm fails to generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may produce multiple outputs that can be combined as needed to generate a sufficiently long key.

[0059] At block 212, transmitting device 204 may employ a selected cryptographic algorithm and use the master symmetric key to process the counter value. For example, the sender may select a symmetric encryption algorithm and use a counter that is updated with each conversation between transmitting device 204 and receiving device 208. Transmitting device 204 can then encrypt the counter value with the selected symmetric encryption algorithm using the master symmetric key, thereby creating a distributed symmetric key.

[0060] In some examples, the counter value may not be encrypted. In these examples, at box 212, the counter value can be transmitted between transmitting device 204 and receiving device 208 without encryption, as per specification page 6 / 26, 9 CN 121444116 A.

[0061] At box 214, the distributed symmetric key can be used to process sensitive data before transmitting the result to receiving device 208. For example, transmitting device 204 can use a symmetric encryption algorithm to encrypt the sensitive data using the distributed symmetric key, wherein the output includes protected encrypted data.The transmitting device 204 can then transmit the protected encrypted data along with the counter value to the receiving device 208 for processing.

[0062] At block 216, the receiving device 208 can first obtain the counter value and then use the counter value as the input for encryption, and use the master symmetric key as the encryption key to perform the same symmetric encryption. The encrypted output can be the same distributed symmetric key value created by the sender.

[0063] At block 218, the receiving device 208 can then obtain the protected encrypted data and use a symmetric decryption algorithm along with the distributed symmetric key to decrypt the protected encrypted data.

[0064] At block 220, as a result of decrypting the protected encrypted data, the original sensitive data may be exposed.

[0065] The next time sensitive data needs to be sent from the sender to the receiver via the corresponding transmitting device 204 and receiving device 208, different counter values ​​can be selected, thereby generating different distributed symmetric keys. By processing the counter value with the master symmetric key and the same symmetric cryptographic algorithm, both the transmitting device 204 and the receiving device 208 can independently generate the same distributed symmetric key. This distributed symmetric key (instead of the master symmetric key) is used to protect sensitive data.

[0066] As described above, the transmitting device 204 and the receiving device 208 initially each have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Because the distributed symmetric key is created independently by the transmitting device 204 and the receiving device 208, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the distributed symmetric key and will never see any data processed with the master symmetric key. Only the master symmetric key is used to process the counter value, not the sensitive data. As a result, side-channel data exposure regarding the master symmetric key is reduced. Furthermore, the operation of the transmitting device 204 and the receiving device 208 can be controlled by the symmetric requirement of the frequency of creating new distributed values ​​(and thus creating new distributed symmetric keys). In one embodiment, a new distributed value can be created for each exchange between the transmitting device 204 and the receiving device 208, and thus a new distributed symmetric key can be created.

[0067] In some examples, the key distributed value may include a counter value. Other non-limiting examples of key dispersion values ​​include: random numbers generated each time a new dispersion key is needed, transmitted from transmitting device 204 to receiving device 208; the full value of a counter value sent from transmitting device 204 and receiving device 208; a portion of a counter value sent from transmitting device 204 and receiving device 208; a counter maintained independently by transmitting device 204 and receiving device 208 but not transmitted between the two devices; a one-time cipher exchanged between transmitting device 204 and receiving device 208; and cryptographic hashes of sensitive data.In some examples, parties may use one or more portions of a key dispersion value to create multiple dispersion keys. For example, a counter may be used as a key dispersion value. Furthermore, combinations of one or more of the exemplary key dispersion values ​​described above may be used.

[0068] In another example, a portion of a counter may be used as a key dispersion value. If multiple master key values ​​are shared between parties, multiple dispersion key values ​​can be obtained through the systems and processes described herein. New dispersion values ​​may be created frequently as needed, thereby creating new dispersion symmetric keys. In the most secure case, a new dispersion value may be created for each sensitive data exchange between transmitting device 204 and receiving device 208. In practice, this can create one-time use keys, such as one-time session keys.

[0069] Figure 3 illustrates an example configuration of contactless card 1204, which may include contactless cards, payment cards, such as credit cards, debit cards, or gift cards issued by a service provider (as shown by service provider marking 302 on the front or back of contactless card 1204). In some examples, contactless card 1204 is not related to payment cards and may include, but is not limited to, identity cards. In some examples, the transaction card may include a dual-interface contactless payment card and a reward card, etc. The contactless card 1204 may include a substrate 308, which may include a single layer or one or more laminates made of plastic, metal and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper and biodegradable materials. In some examples, the contactless card 1204 may have physical characteristics conforming to the ID-1 format of the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 7816 standard, and the transaction card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 1204 according to this disclosure may have different characteristics, and this disclosure does not require the transaction card to be implemented as a payment card.

[0070] The contactless card 1204 may also include identification information 306 displayed on the front and / or back of the card, and a contact pad 304. Contact pad 304 may include one or more pads and is configured to establish communication with another client device (such as an ATM, user equipment, smartphone, laptop, desktop, or tablet) via a transaction card. Contact pad 304 may be designed according to one or more standards (such as the ISO / IEC 7816 standard) and is capable of communicating according to the EMV protocol. Contactless card 1204 may also include processing circuitry, antennas, and other components, as will be discussed further in Figure 4.These components may be located behind the contact pad 304 or elsewhere on the substrate 308, for example, within different layers of the substrate 308, and may be electrically and physically coupled to the contact pad 304. The contactless card 1204 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card (not shown in FIG3). The contactless card 1204 may also include an NFC device coupled to an antenna and capable of communicating via the NFC protocol. Embodiments are not limited to this manner.

[0071] As shown in FIG4, the contact pad 304 of the contactless card 102 may include processing circuitry 416 for storing, processing, and communicating information, including a processor 402, a memory 404, and one or more interfaces 406. It should be understood that the processing circuitry 416 may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware.

[0072] The memory 404 may be a read-only memory, a write-multiple-read memory, or a read / write memory, such as random access memory (RAM), read-only memory (ROM), and erasable programmable ROM (EPROM), and the contactless card 102 may include one or more of these memories. A read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read multiple times. A write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. A read / write memory can be programmed and reprogrammed many times after leaving the factory. A read / write memory can also be read multiple times after leaving the factory. In some cases, the memory 404 may be an encrypted memory that uses an encryption algorithm executed by the processor 402 to encrypt data.

[0073] The memory 404 may be configured to store one or more applets 408, one or more counters 410, a customer identifier 414, and one or more accounts 412, where the account 412 may be a virtual account. One or more applets 408 may include one or more software applications configured to execute on one or more contactless cards, such as Java® card applets. However, it should be understood that one or more applets 408 are not limited to Java® card applets, but may be any software application that can operate on a contactless card or other memory-limited device. One or more counters 410 may include numeric counters sufficient to store integers. A customer identifier 414 may include a unique alphanumeric identifier assigned to 102 users of the contactless card, and the customer identifier 414 distinguishes the user of the contactless card from other contactless card users.In some examples, the customer identifier 414 can identify both the customer and the account assigned to that customer, and can also identify the contactless card 102 associated with the customer's account. As described above, one or more accounts 412 can include thousands of one-time-use virtual accounts associated with the contactless card 102. One or more specifications of the contactless card 102, page 8 / 26, 11 CN 121444116 A, an app 408 can be configured to manage one or more accounts 412 (e.g., select one or more accounts 412, mark the selected one or more accounts 412 as used, and transfer one or more accounts 412 to a mobile device for autofill via an autofill service).

[0074] The processor 402 and memory 404 elements of the exemplary embodiments described above are described with reference to contact pad 304, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of contact pad 304, or completely separate from it, or as further elements in addition to the processor 402 and memory 404 elements located within contact pad 304.

[0075] In some examples, the contactless card 102 may include one or more antennas 418. One or more antennas 418 The processing circuitry 416 can be placed within the contactless card 102 and surrounding the contact pad 304. For example, one or more antennas 418 can be integrated with the processing circuitry 416, and one or more antennas 418 can be used with an external reinforcement coil. As another example, one or more antennas 418 can be external to the contact pad 304 and the processing circuitry 416.

[0076] In one embodiment, the coil of the contactless card 102 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 102 by cutting off the power or by amplitude modulation. The contactless card 101 can infer data transmitted from the terminal by utilizing gaps in the contactless card power connection, the function of which can be maintained by one or more capacitors. The contactless card 102 can communicate in reverse by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference. More generally, using one or more antennas 418, a processor 402, and / or a memory 404, the contactless card 102 provides a communication interface for communication via NFC, Bluetooth, and / or Wi-Fi communication.

[0077] As described above, the contactless card 102 can be built on a software platform operable on smart cards or other memory-limited devices such as JavaCards, and can securely execute one or more applications or applets. One or more applets 408 can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases.One or more applets 408 may be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader, e.g., a mobile device or point-of-sale terminal) and generate an NDEF message including a cryptographically secure OTP encoded as a near-field data exchange (NDEF) text tag.

[0078] An example of an NDEF OTP is an NDEF short record layout (SR=1). In this example, one or more applets 408 may be configured to encode the OTP as a known type of text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. One or more applets 408 may be configured to add one or more static tag records in addition to the OTP record.

[0079] In some examples, one or more applets 408 may be configured to simulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, different cryptographic data is presented each time the tag is read, which may indicate the authenticity of the contactless card. Based on one or more applets 408, NFC reading of the tag can be processed, data can be transmitted to a server (such as a server in a banking system), and the data can be verified at the server.

[0080] In some examples, the contactless card 102 and the server may include specific data so that the card can be correctly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation occurs, one or more counters 410 may be configured to increment. In some examples, each time data is read from the contactless card 102 (e.g., by a mobile device), one or more counters 410 are transmitted to the server for verification, and it is determined whether one or more counters 410 are equal to (as part of the verification) the server's counter.

[0081] One or more counters 410 may be configured to prevent replay attacks. For example, if ciphertext has been obtained and replayed, the ciphertext will be immediately rejected when one or more counters 410 have been read, used, or otherwise skipped. If one or more counters 410 have not been used, they may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for a transaction. Because there is no communication between one or more applets 408 on the contactless card 102, the contactless card 102 cannot determine one or more application transaction counters 410.

[0082] In some examples, one or more counters 410 may lose synchronization. In some examples, one or more counters 410 may increment in response to unexpected reads that initiate transactions (such as skew reads), but the application will not process one or more counters 410.In some examples, NFC can be enabled when the mobile device 104 is woken up, and the device 104 can be configured to read available tags but will not take any action on the read.

[0083] To keep one or more counters 410 synchronized, an application (such as a background application) can be executed, which will be configured to detect when the mobile device 104 wakes up and synchronizes with the bank's server, indicating a read that has occurred due to the detection, and then move one or more counters 410 forward. In other examples, a hashed one-time password can be used to make a certain window of asynchrony acceptable. For example, if within a threshold of 10, one or more counters 410 can be configured to move forward. However, if within a different threshold number, such as within 10 or 1000, a request to perform resynchronization can be processed, which requests the user to tap, gesture, or otherwise indicate once or more via one or more applications through their device. If one or more counters 410 increment in the appropriate sequence, it can be known that the user has done so.

[0084] The key distribution technique described herein with reference to one or more counters 410, a master key, and a distribution key is an example of an encryption and / or decryption key distribution technique. This example key distribution technique should not be considered a limitation of this disclosure, as this disclosure is equally applicable to other types of key distribution techniques.

[0085] During the creation process of the contactless card 102, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which can be used for encryption and decryption of data. The Triple Data Encryption Standard (DES) (3DES) algorithm can be used by EMV, and the algorithm is implemented by hardware in the contactless card 102. By using the key distribution process, one or more keys can be derived from the master key based on unique identifiable information for each entity that requires the key.

[0086] In some examples, to overcome the vulnerability of the 3DES algorithm, which may be susceptible to vulnerabilities, session keys (such as unique keys for each session) can be derived instead of using the master key; unique card-derived keys and counters can be used as distribution data. For example, each time the contactless card 101 is used in operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. This ultimately results in a triple encryption layer. Session keys can be generated by one or more applets and derived using an application transaction counter employing one or more algorithms (as defined in EMV 4.3, Volume 2, A1.3.1, Common Session Key Derivation).

[0087] Furthermore, the increment for each card can be unique and can be assigned through personalization or algorithmically through some identification information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5.In some examples, the increment can also vary during sequential reading, allowing a card to increment sequentially as 1, 3, 5, 2, 2… The specific sequence or algorithm sequence can be defined at a personalized time or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0088] The authentication message can be delivered as the content of a text NDEF record in hexadecimal American Standard Code for Information Interchange (ASCII) format. In another example, the NDEF record can be encoded in hexadecimal format. In another example, the NDEF record can be encoded in hexadecimal format.

[0089] FIG5 is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. Sequence stream 500 may include a contactless card 502 and a client device 506, which may include an application 504 and a processor specification 10 / 26 pages 13 CN 121444116 A 508.

[0090] At line 512, application 504 communicates with contactless card 502 (e.g., after approaching contactless card 502). Communication between application 504 and contactless card 502 may require contactless card 502 to be close enough to the reader (not shown) of client device 506 to enable NFC data transfer between application 504 and contactless card 502.

[0091] At line 510, after communication is established between client device 506 and contactless card 502, contactless card 502 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when contactless card 502 is read by application 504. In particular, this can occur when reading (e.g., NFC reading) an NDEF tag that can be created according to an NFC data exchange format. For example, a reader application (e.g., application 504) may transmit a message (e.g., a mini-program selection message) with an NDEF-generated mini-program ID. After confirmation of the selection, a series of file selection messages can be transmitted, followed by file read messages. For example, the sequence could include "Select Capability File," "Read Capability File," and "Select NDEF File." At this point, the counter value maintained by the contactless card 502 can be updated or incremented, followed by "Read NDEF File." A message including a header and a shared secret can then be generated. A session key can then be generated. MAC ciphertext can be created from the message, which can include a header and a shared secret. The MAC ciphertext can then be concatenated with one or more random data blocks, and the MAC ciphertext and a random number (RND) can be encrypted using the session key.Subsequently, the ciphertext and header can be concatenated, encoded in ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF File" message).

[0092] The MAC ciphertext can be transmitted as an NDEF tag, and in other examples, the MAC ciphertext can be included as a Uniform Resource Indicator (e.g., as a formatted string). In some examples, application 504 can be configured to transmit a request to contactless card 502 that includes instructions to generate the MAC ciphertext.

[0093] At line 514, contactless card 502 sends the MAC ciphertext to application 504. In some examples, the transmission of the MAC ciphertext occurs via NFC; however, this disclosure is not limited thereto. In other examples, such communication can occur via Bluetooth, Wi-Fi, or other wireless data communication methods. At line 516, application 504 transmits the MAC ciphertext to processor 508.

[0094] At line 518, processor 508 verifies the MAC ciphertext according to instructions from application 504. For example, MAC ciphertext can be verified as explained below. In some examples, MAC ciphertext verification can be performed by a device other than client device 506, such as a server in a banking system that communicates data with client device 506. For example, processor 508 can output MAC ciphertext for transmission to a server in the banking system, which can verify the MAC ciphertext. In some examples, MAC ciphertext can serve as a digital signature for verification purposes. Other digital signature algorithms (such as public-key asymmetric algorithms, such as digital signature algorithms and asymmetric cryptographic algorithms (RSA) or zero-knowledge protocols) can be used to perform this verification.

[0095] Figure 6 illustrates an NDEF short record layout (SR=1) data structure 600 according to an example embodiment. One or more applets can be configured to encode OTP as a known type text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: known type, text, encoded English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalized parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a known index for providing actual dynamic authentication data.

[0096] Figure 7 illustrates a system 700 configured to implement one or more embodiments of the present disclosure. As explained below, During the contactless card creation process, two unique password keys can be assigned to each card.The cryptographic key may include a symmetric key, which can be used for data encryption and decryption. The Triple DES (3DES) algorithm may be used by EMV and implemented by hardware in the contactless card. By using key distribution processing, one or more keys can be derived from the master key based on the unique identifiable information of each entity that requires the key.

[0097] Regarding master key management, for each part of an asset portfolio that issues one or more mini-programs, two issuer master keys 702 and 726 may be required. For example, the first master key 702 may include an issuer ciphertext generation / authentication key (Iss-key-Auth), and the second master key 726 may include an issuer data encryption key (Iss-key-DEK). As further explained herein, these two issuer master keys 702 and 726 are distributed into card master keys 708 and 720, which are unique for each card. In some examples, the Network Profile Record ID (pNPR) 722 and Derived Key Index (pDKI) 724, which serve as background data, can be used to identify which issuer master keys 702, 726 are to be used during the encryption process used for authentication. The system performing authentication can be configured to retrieve the values ​​of pNPR 722 and pDKI 724 of the contactless card during authentication.

[0098] In some examples, to improve the security of the solution, session keys (such as a unique key for each session) can be derived, but as explained above, a unique card derived key and a counter can be used as distributed data instead of using the master key. For example, a different key can be used each time the card is used in an operation to create a Message Authentication Code (MAC) and perform encryption. Regarding session key generation, the key used to generate ciphertext and encrypt data in one or more applets can include a session key based on the card's unique key (Card-Key-Auth 708 and Card-Key-Dek 720). Session keys (Aut-Session-Key 732 and DEK-Session-Key 710) can be generated by one or more applets and derived using an Application Transaction Counter (pATC) 704 employing one or more algorithms. Only the lower two bytes of the 4-byte pATC 704 are used to fit the data into one or more algorithms.In some examples, the four-byte session key derivation method may include: F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(four bytes) F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(four bytes) SK:={(ALG(MK)[F1])||ALG(MK[F2]}, where ALG may include the 3DES Electronic Codebook (ECB) and MK may include the card-uniquely derived master key.

[0099] As described herein, one or more MAC session keys may be derived using the lower two bytes of the pATC 704 counter. The pATC 704 is configured to be updated with each tap of the contactless card, and the card master keys Card-Key-AUTH 708 and Card-Key-DEK 720 are further distributed into session keys Aut-Session-Key 732 and DEK-Session-KEY 710. pATC The 704 counter can be initialized to zero during personalization or app initialization. In some examples, the pATC 704 counter can be initialized during or before personalization and can be configured to increment by one on each NDEF read.

[0100] Furthermore, the update for each card can be unique and can be assigned via personalization or via a pUID or other identification information algorithm. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, the update can also vary during sequential reads, allowing a card to increment repeatedly in the sequence 1, 3, 5, 2, 2, ... The specific sequence or algorithm sequence can be defined at the time of personalization or from one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0101] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format. In some examples, it can consist only of authentication data and an 8-byte random number followed by a MAC of authentication data. In some examples, the random number can precede the ciphertext A and can be a block length. In other examples, there can be no limit to the length of the random number. In further examples, the total data (i.e., the random number ciphertext) can be several times the block size. In these examples, additional 8-byte blocks can be added to match the blocks generated by the MAC algorithm. As another example, if the algorithm used uses 16-byte blocks, a multiple of the block size can be used, or the output can be automatically or manually padded to a multiple of the block size.

[0102] The MAC can be performed by the function key (AUT-Session-Key) 732.The data specified in the ciphertext can be processed using the Javacard signature method ALG_DES_MAC8_ISO9797_1_M2_ALG3, in relation to the verification method of EMV Authorization Request Ciphertext Specification, page 12 / 26, 15 CN 121444116 A (ARQC). The key used for this calculation may include the session key AUT-Session-Key 732, as explained above. As explained above, the lower two bytes of the counter can be used to distribute one or more MAC session keys. As explained below, AUT-Session-Key 732 can be used to encrypt MAC data 706, and the resulting data or ciphertext A 714 and the random number RND can be encrypted using DEK-Session-Key 710 to create ciphertext B or output 718 sent in the message.

[0103] In some examples, one or more Hardware Security Module (HSM) commands can be processed for decryption, such that the final 16 (binary, 32 hexadecimal) bytes may include 3DES symmetric encryption of a random number using Cipher Code Block Chain (CBC) mode and zero IV, followed by MAC authentication data. The key used for this encryption may include a session key DEK-Session-Key 710 derived from Card-Key-DEK 720. In this case, the Application Transaction Value (ATC) value derived from the session key is the least significant byte of the counter pATC 704.

[0104] The following format represents an example embodiment in binary form. Furthermore, in some examples, the first byte may be set to ASCII "A". Specification 13 / 26 pages 16 CN 121444116 A

[0105] Another exemplary format is shown below. In this example, the label may be encoded in hexadecimal format.

[0106] The unique identifier (UID) field of the received message can be extracted to derive the card master key (Card-Key-AUTH 708 and Card-Key-DEK 720) for that specific card from the master keys Iss-Key-AUTH 702 and Iss-Key-DEK 726. Using the card master keys (Card-Key-Auth 708 and Card-Key-DEK 720), the received message counter (pATC) field can be used to derive the session key (AUT-Session-Key 732 and DEK-Session-Key 710) for that specific card. Ciphertext B 718 can be decrypted using DEK-Session-KEY, which produces ciphertext A 714 and RND, and RND can be discarded.The UID field can be used to look up the shared secret of the contactless card, which, together with the Ver, UID, and pATC fields of the message, can be processed by a cryptographic MAC using a recreated AUT-Session-Key to create a MAC output, such as MAC'. If MAC' is the same as ciphertext A 714, this indicates that both message decryption and MAC checks have passed. pATC can then be read to determine if it is valid.

[0107] During an authentication session, one or more ciphertexts can be generated by one or more applications. For example, one or more ciphertexts can be generated as a 3DES MAC using ISO 9797-1 algorithm 3, filled with one or more session keys (such as AUT-Session-Key 732) using method 2. Input data 706 can take the form of: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include lengths in bytes. In some examples, the shared secret may be generated by one or more random number generators, which may be configured to ensure that the random number is unpredictable through one or more security processes, as described on page 14 / 26 of the specification, CN 121444116 A. In some examples, the shared secret may include a random 4-byte binary number known to the authentication service in the personalized time-injected card. During the authentication session, the shared secret may not be provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte to the end of the input data, and 0x'00' bytes that may be added to the end of the resulting data up to an 8-byte boundary. The length of the resulting ciphertext may include 8 bytes.

[0108] In some examples, one advantage of encrypting the non-shared random number as the first block with the MAC ciphertext is that it acts as an initialization vector when using CBC mode with a symmetric encryption algorithm. This allows for "scrambling" between blocks without the need to pre-establish a fixed or dynamic IV.

[0109] By including the Application Transaction Counter (pATC) as part of the data included in the MAC ciphertext, the authentication service can be configured to determine whether a value transmitted in plaintext data has been tampered with. Furthermore, by including the version in one or more ciphertexts, it is more difficult for an attacker to deliberately forge application versions in an attempt to weaken the strength of the ciphertext solution. In some examples, the pATC can start from zero and be updated to 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or lower than a value previously received by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated message may be rejected.In some examples, when pATC is greater than a previously received value, it can be evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds or exceeds the range or threshold, the verification can be considered failed or unreliable. In MAC operation 712, data 706 is processed via MAC using AUT-Session-Key 732 to produce MAC output (ciphertext A) 714, which is encrypted.

[0110] To provide additional protection against brute-force attacks on the key on the exposure card, it is preferable to encrypt the MAC output (ciphertext A) 714. In some examples, the data to be included in the ciphertext or ciphertext A 714 may include: a random number (8), ciphertext (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that may be configured to ensure that the random number is unpredictable through one or more secure processes. The key used to encrypt the data may include a session key. For example, the session key may include DEK-Session-Key 710. In encryption operation 716, the data or ciphertext A 714 and RND are processed using the DEK session key 710 to produce encrypted data, i.e., ciphertext B 718. The MAC output (ciphertext A) 714 can be encrypted using 3DES in cipher block chaining mode to ensure that an attacker must attack all ciphertexts. As a non-limiting example, other algorithms, such as the Advanced Encryption Standard (AES), can be used. In some examples, an initialization vector of 0x'00000000000000000' can be used. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used, because correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its randomness.

[0111] To enable the authentication service to verify one or more ciphertexts provided by one or more applets, the following data must be transmitted from one or more applets to the mobile device in plaintext during the authentication session: determining the version number of the encryption method used and the message format used to verify the ciphertext, which allows the method to be changed in the future; a pUID for retrieving the encrypted asset and deriving the card key; and a pATC for deriving the session key used for the ciphertext.

[0112] Figure 8 illustrates a method 800 for generating ciphertext. For example, at block 802, the Network Profile Record ID (pNPR) and Derived Key Index (pDKI) may be used to identify which issuer master keys are used in the cipher process used for authentication. In some examples, the method may include performing authentication to retrieve the values ​​of the pNPR and pDKI of the contactless card during authentication.

[0113] At block 804, the issuing bank master key can be distributed by combining the card's unique ID number (pUID) with the Personal Area Network (PAN) serial number (PSN) of one or more applets (e.g., payment applets).

[0114] At block 806, Card-Key-Auth and Card-Key-DEK (unique card keys) can be created by distributing the issuing bank master key to generate session keys that can be used to generate MAC ciphertext.

[0115] At block 808, the keys used to generate ciphertext and encrypt data in one or more applets may include the session keys of block 806 based on the card's unique key (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and derived using pATC to obtain session keys Aut-Session-Key and DEK-Session-Key.

[0116] Figure 9 depicts an exemplary process 900 illustrating key distribution according to an example. Initially, the sender and receiver may be equipped with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value, which may be updated at block 902, as well as other data (such as the data to be protected), which may be securely shared with the receiver.

[0117] At block 904, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption-derived session key, and the counter value may also be encrypted by the sender using the data integrity master key to generate a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value may be used during the two encryptions.

[0118] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and receiver in plaintext form (i.e., without encryption).

[0119] At block 906, the data to be protected is cryptographically MAC-operated by the sender using the data integrity session key and a cryptographic MAC algorithm. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT - Session-Key).

[0120] At block 908, the data to be protected can be encrypted by the sender using a session key derived from the data encryption in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data (e.g., each 8 bytes long) and then encrypted using a second session key (DEK - Session-Key).

[0121] At box 910, the encrypted MAC is transmitted from the sender to the receiver, containing sufficient information to identify additional secret information (such as a shared secret, master key, etc.) for verification of the ciphertext.

[0122] At box 912, the receiver independently derives two derived session keys from the two master keys using the received counter value, as explained above.

[0123] At box 914, the session keys derived from the data encryption are used in conjunction with a symmetric decryption operation to decrypt the protected data. The exchanged data is then subjected to additional processing. In some examples, after extracting the MAC, it is expected that the MAC will be reconstructed and matched. For example, when verifying the ciphertext, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0124] At block 916, the session key derived for data integrity is used in conjunction with the cipher MAC operation to verify that the protected data has not been modified.

[0125] Some examples of the methods described herein can advantageously confirm when authentication success is determined when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is correct. The MAC can only be correct if decryption is successful and a correct MAC value is produced. Successful decryption can indicate that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using the master key known only to the sender (e.g., transmitting device) and the receiver (e.g., receiving device) (page 16 / 26 of specification 19 CN 121444116 A), it can be believed that the contactless card that initially created and encrypted the MAC is indeed genuine. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

[0126] Thereafter, the two derived session keys can be discarded, and the next iteration of the data exchange will update the counter value (returning to block 902), and a new set of session keys can be created (at box 910). In some examples, combined random data can be discarded.

[0127] FIG10 illustrates a method 800 for card activation according to an example embodiment. For example, card activation can be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components previously explained, such as contactless card 102, client device 104, and server.

[0128] In block 1002, the card can be configured to dynamically generate data.In some examples, the data may include information such as account number, card identifier, card verification value, or phone number, which can be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via the systems and methods disclosed herein.

[0129] In block 1004, one or more portions of dynamically generated data may be communicated to an application of the device via NFC or other wireless communication. For example, tapping the card near the device may allow an application of the device to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to assist in card activation, tapping the card may guide the device or prompt the customer to download the associated application from an app store to activate the card. In some examples, the user may be prompted to make a gesture, place or orient the card sufficiently toward the surface of the device, such as at an angle or flat on the surface of the device, close to or near the surface of the device. In response to the card's gesture, placement, and / or orientation being sufficient, the device may continue to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0130] In block 1006, one or more portions of the data may be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data can be transmitted from the device to the issuing bank server for card activation.

[0131] In block 1008, one or more servers can decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, one or more servers can receive encrypted data from the device and can decrypt it to compare the received data with record data accessible to one or more servers. If a successful match is found by the comparison of one or more decrypted portions of the data by one or more servers, the card can be activated. If a failed match is found by the comparison of one or more decrypted portions of the data by one or more servers, one or more procedures can be performed. For example, in response to the determination of a failed match, the user can be prompted to tap, swipe, or wave the card again. In this case, there can be a predetermined threshold, including the number of attempts allowed to activate the card. Alternatively, the user may receive a notification, such as a message on his or her device indicating that the card verification attempt was unsuccessful, and call, email, or text message to the associated service to assist in activating the card; or receive another notification, such as a phone call on his or her device indicating that the card verification attempt was unsuccessful, and call, email, or text message to the associated service to assist in activating the card; or receive another notification, such as an email indicating that the card verification attempt was unsuccessful, and call, email, or text message to the associated service to assist in activating the card.

[0132] In block 1010, one or more servers may transmit a return message based on the successful activation of the card.For example, the device can be configured to receive output from one or more servers indicating that the card has been successfully activated. The device can be configured to display a message indicating successful card activation. Once the card is activated, the card can be configured to stop dynamically generating data to prevent fraudulent use. In this way, the card may not be able to be activated again thereafter, and one or more servers will receive a notification that the card has been activated. Specification 17 / 26 pages 20 CN 121444116 A

[0133] Figures 1 to 10 generally relate to systems and methods for authenticating contactless cards based on information on the contactless card. However, as previously stated, some embodiments disclosed herein may include systems and methods for improving the security of digital transactions with predetermined risk factors. For example, in some embodiments, the systems and methods disclosed herein can determine when a digital transaction initiated in connection with a user account meets at least one predetermined risk factor. In these cases, the systems and methods disclosed herein do not simply execute the digital transaction, but can enhance security before executing the user account to verify that the digital transaction may have been initiated by an authorized user of the user account. Figures 11 to 14 generally relate to these embodiments and provide additional details thereof.

[0134] FIG11 is a block diagram illustrating an example of a mobile device 1102 according to a disclosed embodiment. It should be understood that the mobile device 1102 may be the same as or similar to the client device 104.

[0135] As shown, the mobile device 1102 may include an interface 1104, a memory 1106, a processor 1112, and a display device 1114. The memory 1106 may be configured to store computer instructions configured to be executed by the processor 1112 to cause the processor 1112 to perform specific actions, and the computer instructions may be part of an application 1108 and / or an operating system 1110.

[0136] In some embodiments, the interface 1104 may include one or more antennas, such as short-range communication antennas, one or more user interface devices, such as a keyboard with hard keys or soft keys, and / or a camera, scanner, card reader, or another device capable of reading or capturing images, information, or data within its field of view. Additionally or alternatively, the interface 1104 may include a WiFi interface, a Bluetooth interface, an NFC interface, a serial bus interface, and a Universal Serial Bus (USB), etc.

[0137] In some embodiments, memory 1106 may be any type of memory configured to store instructions to be processed by processor 1112. Examples of memory 1106 may include volatile or nonvolatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory, etc.

[0138] In some embodiments, processor 1112 may be any type of processor, microprocessor, circuit, circuit element (e.g., transistor, resistor, capacitor, inductor, etc.), integrated circuit, application-specific integrated circuit (ASIC), programmable logic device (PLD), digital signal processor (DSP), field-programmable gate array (FPGA), and multi-core processor, etc.

[0139] In some embodiments, display device 1114 may include a display screen or other output device for displaying data, information, and / or graphics to a user of mobile device 1102.

[0140] As described above, memory 1106 may include application 1108 and / or operating system 1110. Application 1108 may include any type of application configured to operate on mobile device 1102. For example, application 1108 may include social networking applications, communication applications, business productivity applications (e.g., email, word processor, spreadsheet, etc.), storefront applications, remittance applications, gaming applications, merchant applications, and shopping mobile applications, etc. Particularly relevant to some embodiments disclosed herein, application 1108 may include mobile banking applications and / or mobile credit card applications.

[0141] Application 1108 may be configured to operate within operating system 1110. In some embodiments, operating system 1110 may be an Android® operating system, an Apple iOS® operating system, and a Windows Mobile® operating system, etc. Operating system 1110 may be configured to provide services and instructions that are executed and enable application 1108 to operate with hardware. For example, operating system 1110 may be configured to operate with hardware associated with processor 1112 to process detection performed by interface 1104. In some embodiments, operating system 1110 may provide application 1108 with data processed by operating system 1110. Application 1108 may process such data, including performing authentication of the data, transferring the data to other devices or servers, etc. In some embodiments, at least a portion of operating system 1110 may be configured to perform one or more authentication and / or verification steps.

[0142] FIG12 is a block diagram illustrating an example of system 1200 according to the disclosed embodiments. As shown in the figure, System 1200 Specification (pages 18 / 26, CN 121444116 A) may include a mobile device 1202 and a contactless card 1204. It should be understood that the mobile device 1202 may be the same as or similar to the mobile device 1102 and / or the client device 104. It should also be understood that the contactless card 1204 may be the same as or similar to the contactless card 102. The contactless card 1204 may be associated with a user account of the bank or company that issued the contactless card 1204, and the telephone number of the mobile device 1202 may also be associated with that user account.

[0143] In some embodiments, a digital transaction may be initiated via an internet browser on a desktop computer or mobile device 1202 or via a mobile application on the mobile device 1202 associated with a user account. Regardless of where the digital transaction is initiated, the systems and methods disclosed herein can determine whether the digital transaction meets at least one predetermined risk factor. For example, in some embodiments, the mobile device 1202 and / or a server communicating with the desktop computer or mobile device 1202 can determine whether the digital transaction meets at least one predetermined risk factor.

[0144] When a digital transaction meets at least one predetermined risk factor, the systems and methods disclosed herein can request communication between the contactless card 1204 and the mobile device 1202. For example, the desktop computer and / or mobile device 1202 can display or issue a request for communication between the contactless card and the mobile device 1202. When the digital transaction is initiated via an internet browser on the desktop computer or mobile device 1202, the request may include instructions to access a mobile application on the mobile device 1202.

[0145] The user can then tap or otherwise bring the contactless card 1204 into the communication range of the mobile device, and the mobile device 1202 can read ciphertext from the contactless card 1204 and / or the contactless card 1204 can transmit ciphertext to the mobile device 1202. In operation, the mobile device 1202 and / or the server can verify the ciphertext to identify the user account and confirm that the contactless card 1204 is associated with the user account. Specifically, when the user account identified by the ciphertext matches the user account that initiated the digital transaction, the mobile device 1202 and / or the server can confirm that the contactless card is associated with the user account. In some embodiments, the mobile device 1202 can successfully decrypt the ciphertext to identify the user account. Specifically, in some embodiments, the mobile device 1202 can decrypt the protected data in the ciphertext and compare the protected data with recorded data associated with the contactless card 1204 and stored on the mobile device 1202 and / or the server. When the protected data matches the recorded data, the mobile device 1202 can identify the user account associated with it. However, in some embodiments, the mobile device 1202 can transmit the ciphertext to a server to verify the ciphertext and identify the user account, for example, as shown in Figures 1 to 10. Specifically, in some embodiments, the server can decrypt the protected data in the ciphertext and compare the protected data with recorded data associated with the contactless card 1204 and stored on the server. When the protected data matches the recorded data, the server can identify the user account associated with it.

[0146] When the ciphertext has been verified, the user account has been identified, and the contactless card 1204 has been confirmed to be associated with the user account, the mobile device 1202 and / or the server can verify that the mobile device's phone number is associated with the user account.For example, in some embodiments, mobile device 1202 and / or the server may call or otherwise contact or connect to a mobile network operator to identify the mobile device's phone number. In these embodiments, mobile device 1202 and / or the server may contact the backend mobile network operator to request the phone number associated with the mobile device, thereby performing silent mobile authentication. However, in some embodiments, mobile device 1202 may transmit its phone number to the server to verify whether the phone number in mobile device 1202 is associated with a user account. In these embodiments, silent mobile authentication may include the mobile application, mobile device 1202, and / or the server contacting the mobile network operator via a cellular phone system and similar systems to verify whether the phone number of mobile device 1202 matches data maintained by the mobile network operator. For example, the mobile application, mobile device 1202, and / or the server may transmit the mobile device's phone number to the mobile network operator, and the mobile network operator may search its data (e.g., data storage, databases, etc.) to determine whether a match has been identified. When a mobile network operator matches the phone number of mobile device 1202 with data maintained by that operator, the mobile network operator may transmit a verification message to the mobile application, mobile device 1202, and / or server. Specification 19 / 26 pages 22 CN 121444116 A

[0147] In some embodiments, silent mobile authentication may also verify that the SIM card of mobile device 1202 has not been fraudulently exchanged. In practice, when a SIM card is legally exchanged into mobile device 1202, the International Mobile Subscriber Identity (IMSI) code of the SIM card is associated with the phone number of mobile device 1202. However, when a SIM card is fraudulently exchanged, such network operation is not performed. Therefore, the mobile application, mobile device 1202, and / or server may transmit the IMSI number of the SIM card in mobile device 1202 along with the phone number of mobile device 1202 to the mobile network operator, and the mobile network operator may search its data to determine whether the IMSI number of the SIM card matches the phone number 1202 of the mobile device. When the mobile network operator matches the IMSI number of the SIM card with the phone number of the mobile device 1202, the mobile network operator transmits a verification message to the mobile application, the mobile device 1202, and / or the server.

[0148] When the ciphertext has been verified, the user account has been identified, and the phone numbers of the contactless card 1204 and the mobile device 1202 have been confirmed and verified as associated with the user account, the mobile device 1202 and / or the server can authorize the execution of digital transactions associated with the user account.For example, in some embodiments, mobile device 1202 and / or server may transmit one or more messages indicating that all security measures have been satisfied to execute a digital transaction associated with a user account. Additionally or alternatively, in some embodiments, mobile device 1202 and / or server may transmit one or more messages containing instructions to execute a digital transaction associated with a user account.

[0149] It should be understood that in some embodiments, the user account associated with contactless card 1204 will not be identified unless the phone number of mobile device 1202 is associated with the user account. Additionally or alternatively, it should be understood that in some embodiments, the phone number of mobile device 1202 will not be verified as associated with the user account unless the user account is associated with contactless card 1204. In this respect, if these conditions are not met, mobile device 1202 and / or server may be unable to decrypt ciphertext and / or protected data in ciphertext, for example, due to a lack of the required key and the like. Additionally or alternatively, if these conditions are not met, mobile device 1202 and / or the server may be able to decrypt the ciphertext and / or the protected data in the ciphertext, but may not be able to match the protected data with any record data stored for the registered card. In this regard, contactless card 1204 may be associated with a user account, and the user account may be associated with mobile device 1202 and / or the phone number of mobile device 1202 in a database or data storage maintained by the server. Thus, mobile device 1202 may provide the server with the ciphertext received from contactless card 1204 along with identification data, such as the identifier of the mobile device and / or the phone number of the mobile device, and the server may use such received information to identify the user account and verify that the user account is associated with mobile device 1202 and / or the phone number of the mobile device.

[0150] FIG13 is a flowchart illustrating an example of method 1300 according to the disclosed embodiments. In some embodiments, mobile devices (such as mobile device 1202, mobile device 1102 and / or client device 104) may perform some or all of method 1300. Additionally or alternatively, in some embodiments, the server communicating with the mobile device may perform some or all of method 1300.

[0151] As shown, method 1300 may include, in 1302, requesting communication between the contactless card and the mobile device when a digital transaction initiated with respect to a user account satisfies at least one predetermined risk factor. For example, in some embodiments, the digital transaction may be initiated via an internet browser on a desktop computer or mobile device, or via a mobile application on the mobile device. Regardless of where the digital transaction is initiated, the processor of the mobile device and / or the server may determine whether the digital transaction satisfies at least one predetermined risk factor.In some embodiments, the desktop computer and / or mobile device may display or issue a request for communication between the contactless card and the mobile device. When a digital transaction is initiated via an internet browser on the desktop computer or mobile device, the request may include instructions to access a mobile application on the mobile device.

[0152] Method 1300 may then include receiving ciphertext from the contactless card, as shown in 1304. For example, in some embodiments (pages 20 / 26, CN 121444116 A), a short-range communication antenna of the mobile device may receive ciphertext from the contactless card.

[0153] After receiving the ciphertext as in 1304, method 1300 may include verifying the ciphertext as in 1306 to identify a user account and confirm that the contactless card is associated with the user account. In particular, when the user account identified by the ciphertext matches the user account that initiated the digital transaction, the mobile device and / or server may confirm that the contactless card is associated with the user account. For example, in some embodiments, a processor of the mobile device and / or server may verify the ciphertext, identify the user account, and / or confirm that the contactless card is associated with the user account. In some embodiments, the processor of the mobile device and / or server can successfully decrypt the ciphertext to verify the ciphertext and / or identify the user account. For example, the processor of the mobile device and / or server can decrypt protected data in the ciphertext, compare the protected data with recorded data associated with a contactless card and stored on the mobile device and / or server, and identify the user account based on the match between the protected data and the recorded data. In embodiments where the server verifies the ciphertext and / or identifies the user account, the interface of the mobile device can transmit the ciphertext to the server and receive one or more indications that the ciphertext has been verified, the user account has been identified, and / or the contactless card has been confirmed to be associated with the user account. For example, the mobile device can transmit one or more data messages including the ciphertext to the server and can receive indication messages including the identifier of the user account and / or the ciphertext has been verified and / or the contactless card has been associated with the user account.

[0154] After the ciphertext has been verified, the user account has been identified, and the contactless card has been confirmed to be associated with the user account (as shown in 1306), method 1300 may include verifying that the mobile device's telephone number is associated with the user account (as shown in 1308). For example, the processor of the mobile device and / or server can identify the mobile device's phone number and compare it with a record number associated with a user account and stored on the mobile device and / or server to determine if they match, thereby verifying that the mobile device's phone number is associated with the user account. In some embodiments, the interface of the mobile device and / or server can call or otherwise contact or connect to a mobile network operator to verify whether the mobile device's phone number matches mobile network operator data.In an embodiment where the server verifies that a mobile device's phone number is associated with a user account, the mobile device's interface may transmit identification data to the server and may receive one or more indications that a recorded number associated with the user account and / or the mobile device's phone number has been verified as associated with the user account.

[0155] After the ciphertext has been verified, the user account has been identified, and both the contactless card and the mobile device's phone number have been confirmed and verified as associated with the user account (as shown in 1308), method 1300 may include authorizing the execution of a digital transaction associated with the user account (as shown in 1310). For example, the processor of the mobile device and / or the server may authorize the execution of the digital transaction. In some embodiments, the interface of the mobile device and / or the server may transmit one or more messages indicating that all security measures have been satisfied to execute the digital transaction associated with the user account. Additionally or alternatively, in some embodiments, the interface of the mobile device and / or the server may transmit one or more messages containing instructions to execute a digital transaction associated with the user account.

[0156] FIG14 illustrates an example of a sequence flow 1400 according to a disclosed embodiment. In some embodiments, verification and / or authentication may be performed by the mobile device 1404. Additionally or alternatively, in some embodiments, verification and / or authentication may be performed by server 1406.

[0157] Digital transactions may be initiated via an internet browser on a desktop computer or mobile device 1404 or via a mobile application on mobile device 1404 associated with a user account. Server 1406 may communicate with desktop computer and / or mobile device 1404. Therefore, regardless of where the digital transaction is initiated, server 1406 can determine whether the digital transaction meets at least one predetermined risk factor. At 1408, when the digital transaction meets at least one predetermined risk factor, server 1406 may request communication between contactless card 1402 and mobile device 1404. Line 1408 may represent communication between server 1406 and mobile device 1404, and may include instructions to launch the mobile application and / or display or issue a request for communication between contactless card 1402 and mobile device 1404. In some embodiments, in addition to transmitting such instructions to the mobile device 1404, the server 1406 may also transmit instructions to a desktop computer to display or issue a request for communication between the contactless card 1402 and the mobile device 1404.

[0158] At 1410, the contactless card 1402 may be tapped or brought into the communication range of the mobile device 1404 and may exchange information with the mobile device 1404.Line 1410 may represent communication between contactless card 1402 and mobile device 1404, and may include ciphertext stored on contactless card 1402 and provided to mobile device 1404. In some embodiments, the protected data in the ciphertext may be encrypted using the systems and methods described herein, for example, as shown in Figures 1 through 10.

[0159] In some embodiments, communication between contactless card 1402 and mobile device 1404 may include NFC communication according to one or more NFC protocols. However, the embodiments disclosed herein are not limited thereto, and may include other wireless technologies, such as other short-range communication protocols, in addition to NFC or as an alternative to NFC.

[0160] Mobile device 1404 may process the ciphertext received from contactless card 1402. For example, in some embodiments, mobile device 1404 and / or server 1406 may verify the ciphertext to identify a user account and confirm that contactless card 1402 is associated with a user account. In some embodiments, mobile device 1404 may operate as a channel, transmitting ciphertext and other data to server 1406 for verification and authentication, for example, as discussed in Figures 1 through 10.

[0161] As shown in Figure 14, at 1412, mobile device 1404 may transmit information to server 1406, and at 1414, server 1406 may transmit information to mobile device 1404. Line 1412 may represent communication from mobile device 1404 to server 1406, and line 1414 may represent communication from server 1406 to mobile device 1404. For example, in some embodiments, mobile device 1404 may transmit ciphertext received from contactless card 1402 to server 1406, and server 1406 may transmit to mobile device 1404 an indication that the ciphertext has been verified, the user account has been identified, and / or the contactless card 1402 has been confirmed as associated with the user account. However, in some embodiments, the mobile device 1404 may partially or completely process the ciphertext received from the contactless card 1402 and transmit the processed ciphertext to the server 1406, such as partially or completely decrypted protected data or keys. Additionally or alternatively, in some embodiments, the mobile device 1404 may transmit an information request to the server 1406 requesting data stored on the server 1406, such as recording data, for comparison with protected data in the ciphertext received from the contactless card 1402, and the server 1406 may transmit such requested data to the mobile device 1404. Additionally or alternatively, in some embodiments, the information request transmitted from the mobile device 1404 to the server may request the identification of a user account associated with the contactless card 1402 and / or its associated data, and the server 1406 may transmit such requested data to the mobile device 1404.In some embodiments, mobile device 1404 may store recorded data thereon for comparison with protected data, and / or may store the identifier of a user account and / or data associated therewith for comparison with data associated with mobile device 1404 (including the phone number of mobile device 1404).

[0162] Mobile device 1404 and / or server 1406 may also verify whether the phone number of mobile device 1404 is associated with a user account. As shown in FIG14, at 1416, mobile device 1404 may transmit information to server 1406, and at 1418, server 1406 may transmit information to mobile device 1404. Line 1416 may represent communication from mobile device 1404 to server 1406, and line 1418 may represent communication from server 1406 to mobile device 1404. For example, in some embodiments, mobile device 1404 may transmit the phone number of mobile device 1404 to server 1406, and server 1406 may transmit an indication to mobile device 1404 that the phone number of mobile device 1404 is associated with a user account. Additionally or alternatively, in some embodiments, mobile device 1404 and / or server 1406 may call or otherwise contact the mobile network operator (pages 22 / 26, CN 121444116 A) to verify whether the mobile device's phone number matches the mobile network operator's data. Additionally or alternatively, in some embodiments, mobile device 1404 may transmit an information request to server 1406 requesting data stored on server 1406 and retrieved or identified by server 1406, such as a recorded number, to be compared with the mobile device's phone number, and server 1406 may transmit such request data to mobile device 1404. In some embodiments, mobile device 1404 may store recorded numbers thereon for comparison with mobile device 1404's phone number.

[0163] It should be understood that server 1406 may process some or all of any data, information, and / or requests received from mobile device 1404. For example, in some embodiments, server 1406 may decrypt ciphertext. Additionally or alternatively, in some embodiments, server 1406 may compare received, processed, or retrieved data with data stored thereon to identify additional data and / or identify matches between them.

[0164] It should also be understood that mobile device 1404 may communicate with server 1406 via one or more wireless and / or wired connections. For example, in some embodiments, mobile device 1404 may transmit any data, information, or requests to one or more application interfaces (APIs) hosted by server 1406.Additionally or alternatively, in some embodiments, mobile device 1404 may transmit any data, information, or requests to one or more APIs hosted by a third party, such as a cloud computing provider.

[0165] At 1420, after verifying the encrypted message, identifying the user account, and confirming and / or verifying that both the contactless card and the mobile device's phone number are associated with the user account, mobile device 1404 and / or server 1406 may authorize the execution of a digital transaction associated with the user account. As shown, at 1420, mobile device 1404 and / or server 1406 may exchange information between them to authorize the execution of a digital transaction associated with the user account. Line 1420 may represent communication between mobile device 1404 and server 1406. For example, in some embodiments, mobile device 1404 and / or server 1406 may transmit one or more messages and / or instructions to authorize the execution of a digital transaction associated with the user account. In some embodiments, in addition to communicating with or instead of communicating with mobile device 1404, server 1406 may also transmit communications, messages, and / or instructions to one or more other devices (such as third-party servers, etc.) to authorize the execution of digital transactions associated with a user account.

[0166] FIG15 illustrates an embodiment of an exemplary computer architecture 1500 suitable for implementing the various embodiments as described above. In one embodiment, computer architecture 1500 may include or be implemented as part of one or more systems or devices discussed herein.

[0167] As used herein, the terms “system” and “component” are intended to refer to computer-related entities: hardware, combinations of hardware and software, software or software in execution, examples of which are provided by the exemplary computing computer architecture 1500. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, an application running on a server and the server itself may both be components. One or more components may reside in a process and / or execution thread, and components may be localized on a single computer and / or distributed across two or more computers. Furthermore, components may communicate and couple with each other to coordinate operation via various types of communication media. Coordination may involve one-way or two-way information exchange. For example, components may convey information in the form of transmitted signals via a communication medium. This information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, other embodiments may alternatively employ data messages. Such data messages can be sent via various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0168] The computing architecture 1500 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, and power supplies, etc. However, these embodiments are not limited to those implemented by the computing architecture 1500.

[0169] As shown in FIG15, the computing architecture 1500 includes a processor 1512, a system memory 1504, and a system bus 1506. The processor 1512 can be any of a variety of commercially available processors.

[0170] The system bus 1506 provides interfaces for system components, including but not limited to the system memory 1504 to the processor 1512. The system bus 1506 can be any of several types of bus architectures that can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 1506 via a slot architecture. Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), Peripheral Device Interconnect (PCI) Express, Personal Computer Memory Card International Association (PCMCIA), and similar architectures.

[0171] Computing architecture 1500 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and similar code. The embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to perform the operations described herein.

[0172] System memory 1504 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as ROM, RAM, dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), EEPROM, flash memory, polymer memory (such as ferroelectric polymer memory), austenite memory, phase change or ferroelectric memory, silicon oxide silicon oxynitride (SONOS) memory, magnetic cards or optical cards, arrays of devices (such as redundant array of independent disks (RAID) drives), solid-state memory devices (e.g., USB memory), solid-state drives (SSDs), and any other type of storage media suitable for storing information. In the embodiment shown in FIG. 15, system memory 1504 may include non-volatile memory 1508 and / or volatile memory 1510. The basic input / output system (BIOS) may be stored in non-volatile memory 1508.

[0173] Computer 1502 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including an internal (or external) hard disk drive 1530, a disk drive 1516 for reading or writing to a removable disk 1520, and an optical disc drive 1528 for reading or writing to a removable optical disc 1532 (e.g., a CD-ROM or DVD). Hard disk drive 1530, disk drive 1516, and optical disc drive 1528 may be connected to system bus 1506 via hard disk drive (HDD) interface 1514, floppy disk drive (FDD) interface 1518, and optical disc drive interface 1534, respectively. HDD interface 1514 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0174] Drives and associated computer-readable media provide volatile and / or non-volatile storage devices for data, data structures, and computer-executable instructions, etc. For example, many program modules may be stored in the drive, non-volatile memory 1508, and volatile memory 1510, including operating system 1522, one or more applications 1542, other program modules 1524, and program data 1526. In one embodiment, one or more applications 1542, other program modules 1524, and program data 1526 may include various applications and / or components of, for example, the systems discussed herein.

[0175] Users may input commands and information to computer 1502 through one or more wired / wireless input devices (e.g., keyboard 1550 and pointing devices such as mouse 1552, etc., specification page 24 / 26, 27 CN 121444116 A).Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and similar input devices. These and other input devices are typically connected to the processor 1512 via input device interface 1536 coupled to system bus 1506, but may be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, and IR interfaces.

[0176] Display 1544 or other types of display devices are also connected to system bus 1506 via an interface such as video adapter 1546. Display 1544 may be located inside or outside computer 1502. In addition to display 1544, the computer typically includes other peripheral output devices such as speakers and printers.

[0177] Computer 1502 can operate in a networked environment using logical connections to one or more remote computers (such as one or more remote computers 1548) via wired and / or wireless communications. One or more remote computers 1548 may be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer-to-peer devices, or other public network nodes, and typically include many or all of the elements described relative to computer 1502, although for brevity only memory and / or storage devices 1558 are shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1556 and / or a larger network (e.g., a wide area network 1554). Such LAN and wide area network (WAN) networking environments are common in offices and companies and facilitate enterprise-wide computer networks (such as intranets), all of which can connect to global communication networks (e.g., the Internet).

[0178] When used in a LAN 1556 networking environment, computer 1502 connects to LAN 1556 via a wired and / or wireless communication network interface or network adapter 1538. Network adapter 1538 can facilitate wired and / or wireless communication with local area network 1556, which may also include a wireless access point thereon for communicating with the wireless capabilities of network adapter 1538.

[0179] When used in a wide area network 1554 networking environment, computer 1502 may include modem 1540, or a communication server connected to wide area network 1554, or have other means for establishing communication on wide area network 1554, such as via the Internet. Modem 1540 may be internal or external and may be a wired and / or wireless device connected to system bus 1506 via input device interface 1536.In a networked environment, the program modules or portions thereof depicted relative to computer 1502 may be stored in remote memory and / or storage device 1558. It should be understood that the network connections shown are exemplary and other means of establishing communication links between computers may be used.

[0180] Computer 1502 is operable to communicate with wired and wireless devices or entities using IEEE 802 series standards, such as wireless devices operable in wireless communication (e.g., IEEE 802.11 air modulation technology). This includes at least Wi-Fi (or wireless LAN), WiMax, and Bluetooth™ wireless technologies and others. Therefore, the communication may be a predefined structure like a conventional network, or simply self-organizing communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use media and functions associated with IEEE 802.3).

[0181] The various elements of the device as described above may include a variety of hardware elements, software elements, or combinations thereof. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, and inductors), integrated circuits, application-specific integrated circuits (ASICs), PLDs, DSPs, field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, and chipsets. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, APIs, instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware and / or software components can vary depending on many factors, such as desired computing speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints required for a given implementation.

[0182] The components and features of the above-described device can be implemented using any combination of discrete circuits, ASICs, logic gates, and / or monolithic architectures. Furthermore, where appropriate, the features of the device can be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof.It should be noted that hardware, firmware, and / or software elements may be collectively referred to or individually as “logic” or “circuit” herein.

[0183] FIG16 is a block diagram depicting an exemplary communication architecture 1600 suitable for implementing the various embodiments described above. Communication architecture 1600 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, and power supplies. However, embodiments are not limited to those implemented by communication architecture 1600 and may be consistent with the systems and devices discussed herein.

[0184] As shown in FIG16, communication architecture 1600 includes one or more clients 1602 and one or more servers 1604. One or more servers 1604 may implement one or more functions and embodiments discussed herein. One or more clients 1602 and one or more servers 1604 are operatively connected to one or more corresponding client data stores 1606 and server data stores 1608, which may be used to store information local to one or more corresponding clients 1602 and one or more servers 1604, such as cookies and / or associated context information.

[0185] One or more clients 1602 and one or more servers 1604 may use the communication framework 1610 to communicate information to each other. The communication framework 1610 may implement any known communication technology and protocol. The communication framework 1610 may be implemented as a packet-switched network (e.g., a public network such as the Internet, and a private network such as a corporate intranet), a circuit-switched network (e.g., a public switched telephone network), or a combination of packet-switched and circuit-switched networks (with suitable gateways and converters).

[0186] The communication framework 1610 may implement various network interfaces arranged to receive, communicate, and connect to the communication network. A network interface may be considered a special form of input / output (I / O) interface. The network interface may employ connectivity protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000BaseT, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, and similar network interfaces. Furthermore, multiple network interfaces can be used to interface with various communication network types. For example, multiple network interfaces can be used to allow communication over broadcast, multicast, and unicast networks. If processing requirements dictate greater speed and capacity, a similar distributed network controller architecture can be employed to pool, load balance, and otherwise increase the communication bandwidth required by one or more clients 1602 and one or more servers 1604.The communication network can be any type and combination of wired and / or wireless networks, including but not limited to direct interconnection, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), PANs, LANs, metropolitan area networks (MANs), Operational Missions as Internet Nodes (OMNIs), WANs, wireless networks, cellular networks, and other communication networks. Instruction manual, page 26 / 26, 29 CN 121444116 A, Figure 1, Figure 2, Instruction manual drawing 1 / 15, page 30 CN 121444116 A, Figure 3, Instruction manual drawing 2 / 15, page 31 CN 121444116 A, Figure 4, Instruction manual drawing 3 / 15, page 32 CN 121444116 A, Figure 5, Instruction manual drawing 4 / 15, page 33 CN 121444116 A, Figure 6, Instruction manual drawing 5 / 15, page 34 CN 121444116 A, Figure 7, Instruction manual drawing 6 / 15, page 35 CN 121444116 A, Figure 8, Instruction manual drawing 7 / 15, page 36 CN 121444116 A, Figure 9, Instruction manual drawing 8 / 15, page 37 CN 121444116 A, Figure 10, Instruction manual drawing 9 / 15, page 38 CN 121444116 A, Figure 11 Figure 12 of the instruction manual, page 10 / 15, 39 CN 121444116 A; Figure 13 of the instruction manual, page 11 / 15, 40 CN 121444116 A; Figure 14 of the instruction manual, page 13 / 15, 42 CN 121444116 A; Figure 15 of the instruction manual, page 14 / 15, 43 CN 121444116 A; Figure 16 of the instruction manual, page 15 / 15, 44 CN 121444116 A.

Claims

1. A method comprising: requesting communication between a contactless card and a mobile device when a digital transaction initiated in association with a user account satisfies at least one predetermined risk factor; receiving, by a short-range communication antenna of the mobile device, a cryptogram from the contactless card; verifying, by a processor of the mobile device, the cryptogram to identify the user account and confirm that the contactless card is associated with the user account; verifying, by the processor of the mobile device, that a phone number of the mobile device is associated with the user account; and authorizing performance of the digital transaction associated with the user account when both the contactless card and the phone number of the mobile device are associated with the user account.

2. The method of claim 1, wherein, The digital transaction comprises a wire transfer.

3. The method of claim 1, wherein, The at least one predetermined risk factor comprises a value of the digital transaction reaching or exceeding a predetermined monetary amount.

4. The method of claim 1, wherein, The at least one predetermined risk factor comprises the digital transaction originating from a suspicious location, a suspicious device, or a suspicious Internet Protocol (IP) address.

5. The method of claim 1, further comprising: successfully decrypting the cryptogram to verify the cryptogram and identify the user account.

6. The method of claim 5, further comprising: decrypting protected data in the cryptogram; comparing the protected data to stored record data associated with the contactless card; and identifying the user account based on a match between the protected data and the stored record data.

7. The method of claim 1, further comprising: transmitting the cryptogram from the mobile device to a server; and receiving, at the mobile device, one or more indications that the cryptogram and the phone number of the mobile device have been verified.

8. The method of claim 7, further comprising: transmitting one or more messages from the mobile device to the server.

9. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the following operations: requesting communication between a contactless card and a mobile device when a digital transaction initiated in association with a user account satisfies at least one predetermined risk factor; receiving, via a short-range communication antenna of the mobile device, a cryptogram from the contactless card; verifying the cryptogram to identify the user account and confirm that the contactless card is associated with the user account; verifying that a phone number of the mobile device is associated with the user account; and authorizing performance of the digital transaction associated with the user account when both the contactless card and the phone number of the mobile device are associated with the user account.

10. The non-transitory computer readable medium of claim 9, wherein, The digital transaction comprises a wire transfer.

11. The non-transitory computer readable medium of claim 9, wherein, The at least one predetermined risk factor comprises a value of the digital transaction reaching or exceeding a predetermined monetary amount.

12. The non-transitory computer-readable medium of claim 9, wherein, The at least one predetermined risk factor comprises the digital transaction originating from a suspicious location, a suspicious device, or a suspicious IP address.

13. The non-transitory computer-readable medium of claim 9, wherein, The instructions further cause the processor to successfully decrypt the cryptogram to verify the cryptogram and identify the user account.

14. The non-transitory computer-readable medium of claim 13, wherein, The instructions cause the processor to further perform the following operations: decrypting protected data in the ciphertext; comparing the protected data to stored record data associated with the contactless card; and identifying the user account based on a match between the protected data and the stored record data.

15. The non-transitory computer-readable medium of claim 13, wherein, The instructions cause the processor to further perform operations of: transmitting the ciphertext to a server; and receiving one or more indications that the ciphertext and a phone number of the mobile device have been verified.

16. The non-transitory computer readable medium of claim 15, wherein, The instructions further cause the processor to transmit one or more messages to the server.

17. A mobile device, the mobile device comprising: a short-range communication antenna; a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform operations of: requesting communication with a contactless card when a digital transaction initiated in association with a user account satisfies at least one predetermined risk factor; receiving, via the short-range communication antenna, a ciphertext from the contactless card; verifying the ciphertext to identify the user account and confirm that the contactless card is associated with the user account; verifying that a phone number of the mobile device is associated with the user account; and authorizing performance of the digital transaction in association with the user account when both the contactless card and the phone number of the mobile device are associated with the user account.

18. The mobile device of claim 17, the mobile device further comprising: a user interface device, wherein the instructions further cause the processor to display or emit, on the user interface device, a request to communicate with the contactless card.

19. The mobile device of claim 17, the mobile device further comprising: an internet browser or a mobile application, wherein the digital transaction is initiated via the internet browser or the mobile application. The digital transaction is initiated via an internet browser on a desktop computer.

20. The mobile device of claim 17, wherein, ​

Images