System and method for enhancing security of logging in mobile application

Abstract

Systems and methods for enhancing security of logging into a mobile application are provided. A short range communication antenna of the mobile device may receive a ciphertext from the contactless card, and a processor of the mobile device may verify the ciphertext to identify a customer account associated with the contactless card and verify that a phone number of the mobile device is associated with the customer account. A user interface device of the mobile device may then receive enhanced security input data, and a processor of the mobile device may verify that the enhanced security input data matches enhanced security record data associated with the customer account. The systems and methods disclosed herein may log in to a mobile application running on a mobile device to access a customer account after a ciphertext, a phone number of the mobile device, and enhanced security input data have been validated.

Description

Cross-references to related applications

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

[0002] Systems and methods for secure login to mobile applications are known in the art. However, bad actors are still looking for ways to circumvent known security measures. Summary of the Invention

[0003] In some embodiments, a method may include: receiving ciphertext from a contactless card via a short-range communication antenna of a mobile device; verifying the ciphertext via a processor of the mobile device to identify a customer account associated with the contactless card; verifying that a phone number of the mobile device is associated with the customer account via the processor of the mobile device; receiving enhanced security input data via a user interface device of the mobile terminal; verifying that the enhanced security input data matches enhanced security record data associated with the customer account via the processor of the mobile device; and logging into a mobile application running on the mobile device to access the customer account when the ciphertext, the mobile device's phone number, and the enhanced security input data have been verified.

[0004] In some embodiments, enhanced security input data may include alphanumeric passwords.

[0005] In some embodiments, the user interface device may include a camera of the mobile device, and enhanced security input data may include a selfie of the user captured by the camera during a predetermined period of time during which the encrypted data from the contactless card is received by the short-range communication antenna.

[0006] In some embodiments, enhanced security input data may include biometric input data.

[0007] In some embodiments, in response to verifying ciphertext and the mobile device's phone number, the method may include displaying a request for enhanced secure input data on the mobile device's display.

[0008] In some embodiments, the method may include successfully decrypting the ciphertext to verify the ciphertext and identify the customer account.

[0009] In some embodiments, the method may include decrypting protected data in ciphertext, comparing the protected data with stored record data associated with a contactless card, and identifying a customer account based on the match between the protected data and the stored record data.

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

[0011] In some embodiments, the method may include transmitting one or more messages from a mobile device to a server, and the one or more messages may include ciphertext and enhanced security input data.

[0012] In some embodiments, a non-transitory computer-readable medium may include instructions that, when executed by a processor, cause the processor to perform the following operations: receive ciphertext from a contactless card via a short-range communication antenna of the mobile device; verify the ciphertext to identify a customer account associated with the contactless card; verify that a telephone number of the mobile device is associated with the customer account; receive enhanced security input data via a user interface device of the mobile device; verify that the enhanced security input data matches enhanced security record data associated with the customer account; and, when the ciphertext, the mobile device telephone number, and the enhanced security input data have been verified, log in to a mobile application running on the mobile device to access the customer account.

[0013] In some embodiments, enhanced security input data may include alphanumeric passwords.

[0014] In some embodiments, the user interface device may include a camera, and enhanced security input data may include a selfie captured by the camera during a predetermined period of time during which the short-range communication antenna receives encrypted data from a contactless card.

[0015] In some embodiments, enhanced security input data may include biometric input data.

[0016] In some embodiments, in response to verifying ciphertext and the mobile device's phone number, instructions may cause the processor to display a request for enhanced secure input data on the mobile device's display.

[0017] In some embodiments, the instructions can enable the processor to successfully decrypt the ciphertext in order to verify the ciphertext and identify the customer account.

[0018] In some embodiments, the instructions may cause the processor to 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 a customer account based on the match between the protected data and the stored record data.

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

[0020] In some embodiments, the instructions may cause the processor to transmit one or more messages to the server, and the one or more messages may include ciphertext and enhanced security input data.

[0021] In some embodiments, the mobile device may include a short-range communication antenna, a user interface device, a processor, and a memory storing instructions that, when executed by the processor, cause the processor to perform the following operations: receive ciphertext from a contactless card via the short-range communication antenna; verify the ciphertext to identify a customer account associated with the contactless card; verify that the mobile device's phone number is associated with the customer account; receive enhanced security input data via the user interface device; verify that the enhanced security input data matches enhanced security record data associated with the customer account; and, when the ciphertext, the mobile device's phone number, and the enhanced security input data have been verified, log in to a mobile application running on the mobile device to access the customer account.

[0022] In some embodiments, the mobile device may include a display device, and in response to verifying the ciphertext and the mobile device's phone number, instructions may cause the processor to display a request for enhanced secure input data on the display device.

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

[0024] Figure 1 An example of a system according to one embodiment is shown.

[0025] Figure 2 An example of a system according to one embodiment is shown.

[0026] Figure 3 An example of a contactless card according to one embodiment is shown.

[0027] Figure 4 An example of a transaction card component according to one embodiment is shown.

[0028] Figure 5 An example of a sequence flow according to one embodiment is shown.

[0029] Figure 6 An example of a data structure according to one embodiment is shown.

[0030] Figure 7An example of a key system according to one embodiment is shown.

[0031] Figure 8 An example of a method for generating ciphertext according to one embodiment is shown.

[0032] Figure 9 An example of a key distribution method according to one embodiment is shown.

[0033] Figure 10 An example of a method for card activation according to one embodiment is shown.

[0034] Figure 11 An example of a mobile device according to one embodiment is shown.

[0035] Figure 12 An aspect of a system according to one embodiment is shown.

[0036] Figure 13 An example of a method according to one embodiment is shown.

[0037] Figure 14 An example of a sequence flow according to one embodiment is shown.

[0038] Figure 15 An example of a computer architecture according to one embodiment is shown.

[0039] Figure 16 An example of a communication architecture according to one embodiment is shown. Detailed Implementation

[0040] The embodiments disclosed herein generally relate to systems and methods for enhancing the security of logging into mobile applications on mobile devices. For example, in some embodiments, a multi-pronged security protocol may be implemented to ensure that a predetermined number of security measures are met before allowing a user to log into a mobile application. In some specific embodiments disclosed herein, the predetermined number of security measures may be three and may include: verifying ciphertext received by the mobile device from a contactless card to identify a customer account associated with the contactless card; using silent mobile authentication in the backend to identify a phone number associated with the mobile device and verifying that the mobile device's phone number is associated with the customer account; and verifying that enhanced security input data received by the mobile device matches enhanced security record data archived for the customer account in a database. However, the embodiments disclosed herein are not limited thereto. Rather, it should be understood that the predetermined number of security measures may be more or less than three and may include additional or alternative security measures disclosed and described herein and understood by those skilled in the art.

[0041] Specifically, 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 customer account associated with the contactless card. Then, the mobile device's processor can verify whether the mobile device's phone number is associated with the customer account. When both conditions are met, the mobile device's display can show a request for enhanced security input data, the mobile device's user interface can receive the enhanced security input data, and the mobile device's processor can verify that the enhanced security input data matches the enhanced security record data associated with the customer account. When all three conditions are met—that is, the ciphertext, the mobile device's phone number, and the enhanced security input data have all been verified—the mobile device's processor can log in to the mobile application running on the mobile device to access the customer account.

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

[0043] Additionally or alternatively, in some embodiments, the mobile device may transmit one or more messages, including ciphertext and / or enhanced security input data, to a server communicating with the mobile device. The server may successfully decrypt the ciphertext to verify it and identify the customer account, verify that the mobile device's phone number is associated with the customer account, and / or verify that the enhanced security input data matches enhanced security record data associated with the customer account. Therefore, the mobile device may receive one or more indication messages from the server indicating that the ciphertext, the mobile device's phone number, and / or the enhanced security input data have all been verified.

[0044] Advantageously, the systems and methods disclosed herein can provide enhanced security for logging into mobile applications on mobile devices. In fact, by implementing the multi-pronged security protocols disclosed and described herein, the systems and methods can ensure that login access to a mobile application is blocked unless and until all predetermined numbers of security measures are satisfied. In this regard, a malicious actor possessing a contactless card cannot log into a mobile application without simultaneously possessing a mobile device with a phone number associated with a customer account. Furthermore, even if a malicious actor possesses both a contactless card and a mobile device with a phone number associated with a customer account, he or she still cannot log into the mobile application if he or she does not know and does not enter enhanced security input data matching the enhanced security record data associated with the customer account into the mobile device.

[0045] Additional advantages of the embodiments disclosed herein may include reducing and / or minimizing the number of taps a user makes to log in to a mobile application, thereby reducing and / or minimizing the amount of input data that the processor of the mobile device and / or server must process. For example, in some embodiments, a user can log in to the mobile application simply by placing a contactless card within the communication range of the mobile device's short-range communication antenna and entering enhanced security input data into the mobile device's user interface device. Similarly, the processor of the mobile device and / or server only needs to process the encrypted data, the mobile device's phone number, and the enhanced security input data to log in to the mobile application, thereby reducing processing time and power consumption.

[0046] In some embodiments, enhanced security input data may include alphanumeric ciphertext, such as x-bit ciphertext, a selfie captured by the mobile device's camera during a predetermined period of time when the ciphertext from the contactless card is received by a short-range communication antenna, or biometric input data. Therefore, a further advantage of the embodiments disclosed herein may include avoiding the need for users to input personal information in mobile applications that they may easily forget, such as usernames and traditional passwords.

[0047] The details of the above embodiments and their additional advantages are discussed in the following description.

[0048] Figure 1 A data transmission system 100 according to an example embodiment is illustrated. As discussed further below, system 100 may include a contactless card 102, a client device 104, a network 106, and a server 108. Although Figure 1 A single instance of a component is shown, but system 100 may include any number of components.

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

[0050] 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, thick 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.

[0051] 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.

[0052] In some examples, the client device 104 of system 100 may execute one or more applications, such as software applications, which are capable of communicating over a network with one or more components of system 100 and transmitting and / or receiving data.

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

[0054] 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.

[0055] Additionally, network 106 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 802.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Furthermore, network 106 may support the Internet, wireless communication networks, cellular networks, or similar networks, or any combination thereof. Network 106 may also include a single network, or any number of the 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, depending on one or more examples, network 106 may include multiple interconnected networks, such as, for example, the Internet, service provider networks, cable television networks, corporate networks (such as credit card association networks), and home networks.

[0056] 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 accessing 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.

[0057] Figure 2 A data transmission system according to an example embodiment is illustrated. System 200 may include, for example, a transmitting or sending device 204 and a receiving or receiving device 208 that communicate with one or more servers 202 via network 206. The transmitting or sending device 204 may be the same as described above. Figure 1 The client device 104 discussed is the same as or similar to the one mentioned above. The receiving device 208 can be referenced in the above text. Figure 1 The client device 104 discussed is the same as or similar to the one mentioned above. Network 206 can be similar to the one described above. Figure 1 The discussion focuses on network 106. Server 202 can be similar to the above reference. Figure 1 The server being discussed is 108. Although... Figure 2 A single instance of the components of system 200 is shown, but system 200 may include any number of illustrated components.

[0058] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication codes (HMAC) algorithms, and cryptographic message authentication codes (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.

[0059] 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.

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

[0061] However, by limiting the number of times a specific key can be used, the amount of side-channel data an attacker can collect is limited, thus reducing the risk of such and other types of attacks. As further described herein, the parties involved in exchanging encrypted information (e.g., the sender and 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 currently in use without any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and receiver, the aforementioned attacks become impossible.

[0062] Refer to the return Figure 2 System 200 can be configured to implement key distribution. For example, the sender and receiver may wish to exchange data (e.g., raw sensitive data) via their respective devices 204 and 208. As described above, while a single instance of the transmitting device 204 and the receiving device 208 can 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, the transmitting device 204 and the 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 function of the transmitting device 204, and similarly, any party holding the same secret symmetric key can perform the function of the 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 the transmitting device 204 and the receiving device 208 involved in exchanging secure data. It is also understood that both the transmitting device 204 and the receiving device 208 can be configured with the same master symmetric key, and further, a portion of the data exchanged between the transmitting device 204 and the receiving device 208 includes at least a portion of data that can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the transmitting device 204 and the receiving device 208.

[0063] 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 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.

[0064] 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, or any combination thereof. Network 206 may also include a single 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 in its communication manner. Network 206 may be converted 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, depending on one or more examples, network 206 may include multiple interconnected networks, such as, for example, the Internet, service provider networks, cable television networks, corporate networks (such as credit card association networks), and home networks.

[0065] In some examples, one or more transmitting devices 204 and one or more receiving devices 208 can be configured to communicate with each other and 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 can occur via at least one of NFC, Bluetooth, RFID, Wi-Fi and / or similar technologies.

[0066] At box 210, when the transmitting device 204 is ready to process sensitive data using symmetric cryptographic operations, the sender may update the counter. Additionally, the 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 the scatter value 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 the symmetric algorithm multiple times 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.

[0067] At box 212, transmitting device 204 can employ a selected cryptographic algorithm and use a master symmetric key to process the counter value. For example, the sender can choose 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 using the selected symmetric encryption algorithm with the master symmetric key, thereby creating a distributed symmetric key.

[0068] 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.

[0069] 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, where the output includes protected encrypted data. Transmitting device 204 can then transmit the protected encrypted data along with a counter value to receiving device 208 for processing.

[0070] At box 216, receiving device 208 can first acquire 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.

[0071] At box 218, receiving device 208 can then acquire the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm along with a distributed symmetric key.

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

[0073] The next time sensitive data needs to be transmitted 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 values ​​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.

[0074] As described above, transmitting device 204 and receiving device 208 initially each possess a shared master symmetric key. This shared master symmetric key is not used to encrypt the original sensitive data. Because the distributed symmetric key is created independently by transmitting device 204 and receiving device 208, it is never transmitted between them. 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 counter values, not sensitive data. As a result, side-channel data exposure regarding the master symmetric key is reduced. Furthermore, the operation of transmitting device 204 and receiving device 208 can be controlled by the symmetric requirement of the frequency of creating new distributed values ​​(and thus new distributed symmetric keys). In one embodiment, a new distributed value can be created for each exchange between transmitting device 204 and receiving device 208, and thus a new distributed symmetric key can be created.

[0075] In some examples, the key dispersion value may include a counter value. Other non-limiting examples of key dispersion values ​​include: a random number 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 a cryptographic hash of sensitive data. In some examples, parties may use one or more portions of the key dispersion value to create multiple dispersion keys. For example, a counter may be used as the key dispersion value. Furthermore, combinations of one or more of the exemplary key dispersion values ​​described above may be used.

[0076] In another example, a portion of the counter can be used as a key distribution value. If multiple master key values ​​are shared among the parties, multiple distribution key values ​​can be obtained through the system and process described herein. New distribution values ​​can be created frequently as needed, and thus new distribution symmetric keys can be created. In the most secure scenario, a new distribution value can 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.

[0077] Figure 3 An example configuration of a contactless card 1204 is shown, which may include contactless cards, payment cards, such as credit cards, debit cards, or gift cards, issued by a service provider (as indicated by service provider marking 302 on the front or back of the contactless card 1204). In some examples, the contactless card 1204 is not a payment card 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 rewards card, etc. The contactless card 1204 may include a substrate 308, which may include a single layer or one or more laminates composed of plastics, metals, 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.

[0078] 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. The 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 the transaction card. The 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. The contactless card 1204 may also include processing circuitry, an antenna, and other components, as will be... Figure 4 This will be discussed further in the following section. These components may be located behind the contact pad 304 or elsewhere on the substrate 308, such as 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. Figure 3(Not shown in the image). The contactless card 1204 may also include an NFC device coupled to an antenna, capable of communicating via the NFC protocol. Embodiments are not limited to this approach.

[0079] like Figure 4 As shown, the contact pad 304 of the contactless card 102 may include processing circuitry 416 for storing, processing, and conveying 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, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware.

[0080] Memory 404 can 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 (EEPROM), and the contactless card 102 may include one or more of these memories. Read-only memory can 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. 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. Read / write memory can be programmed and reprogrammed many times after leaving the factory. Read / write memory can also be read multiple times after leaving the factory. In some cases, memory 404 can be encrypted memory that uses an encryption algorithm executed by processor 402 to encrypt data.

[0081] Memory 404 may be configured to store one or more applets 408, one or more counters 410, customer identifier 414, and one or more accounts 412, where 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. Customer identifier 414 may include a unique alphanumeric identifier assigned to the 102 users of the contactless card, and customer identifier 414 distinguishes the user of the contactless card from other contactless card users. In some examples, customer identifier 414 may identify both the customer and the account assigned to that customer, and may also identify the contactless card 102 associated with the customer account. As described above, one or more accounts 412 may include thousands of one-time-use virtual accounts associated with the contactless card 102. One or more applets 408 of the contactless card 102 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).

[0082] The processor 402 and memory 404 elements of the exemplary embodiments described above are illustrated 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 beyond the processor 402 and memory 404 elements located within contact pad 304.

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

[0084] 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 power or by amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using gaps in the contactless card's power connection, the function of which can be maintained by one or more capacitors. The contactless card 102 can communicate in reverse by switching loads 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.

[0085] 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 can 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, for example, a mobile device or point-of-sale terminal) and generate an NDEF message that includes a cryptographically secure OTP encoded as a near-field data exchange (NDEF) text tag.

[0086] An example of NDEF OTP is the NDEF short record layout (SR=1). In this example, one or more applets 408 can be configured to encode the OTP into 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 can be configured to add one or more static tag records in addition to the OTP record.

[0087] In some examples, one or more applets 408 can be configured to simulate RFID tags. RFID tags can include one or more polymorphic tags. In some examples, different cipher data is presented each time a tag is read, and this cipher data can 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.

[0088] 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, determining whether one or more counters 410 are equal to (as part of the verification) the server's counter.

[0089] One or more counters 410 can 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 yet been used, they can 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.

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

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

[0092] 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 as a limitation of this disclosure, as this disclosure is equally applicable to other types of key distribution techniques.

[0093] During the creation process of the contactless card 102, two unique cryptographic keys can be assigned to each card. These cryptographic keys may include symmetric keys, which can be used for data encryption and decryption. The Triple Data Encryption Standard (DES) (3DES) algorithm is available from EMV and is implemented by hardware within the contactless card 102. Through key distribution processing, one or more keys can be derived from the master key based on the unique identifiable information of each entity requiring a key.

[0094] In some examples, to overcome the potential vulnerabilities of the 3DES algorithm, session keys (such as a unique key for each session) can be derived instead of using a master key. Unique card-derived keys and counters can be used to distribute the data. For example, each time a contactless card 101 is used in an 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 application transaction counters employing one or more algorithms (as defined in EMV 4.3, Volume 2, A1.3.1, Common Session Key Derivation).

[0095] Furthermore, the increment for each card can be unique and can be assigned through personalization or algorithmic allocation using some identifying 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 algorithmic sequence can be defined at personalized times 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.

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

[0097] Figure 5This 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 508.

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

[0099] At point 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. Specifically, this can happen when reading (e.g., NFC reading) an NDEF tag that can be created according to the NFC data exchange format. For example, a reader application (e.g., application 504) can transmit a message (e.g., a mini-program selection message) with a mini-program ID that produces the NDEF. After confirming the selection, a series of select file messages can be transmitted, followed by read file messages. For example, the sequence could include "select capability file," "read capability file," and "select NDEF file." At this point, a counter value maintained by contactless card 502 can be updated or incremented, followed by "read NDEF file." A message that may include 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 may 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 random number (RND) can be encrypted using a session key. Afterward, 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).

[0100] The MAC ciphertext can be transmitted as an NDEF tag, and in other examples, it 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.

[0101] 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, this communication may occur via Bluetooth, Wi-Fi, or other wireless data communication methods. At line 516, application 504 transmits the MAC ciphertext to processor 508.

[0102] At line 518, processor 508 verifies the MAC ciphertext according to instructions from application 504. For example, the MAC ciphertext can be verified as explained below. In some examples, the verification of the MAC ciphertext 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 the MAC ciphertext for transmission to a server in the banking system, which can verify the MAC ciphertext. In some examples, the MAC ciphertext can serve as a digital signature for verification purposes. Other digital signature algorithms, such as public-key asymmetric algorithms (e.g., digital signature algorithms and asymmetric cryptographic algorithms (RSA)) or zero-knowledge protocols, can be used to perform this verification.

[0103] Figure 6 A short record layout (SR=1) data structure 600 for NDEF according to an example embodiment is shown. 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.

[0104] Figure 7 A system 700 configured to implement one or more embodiments of the present disclosure is shown. As explained below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which can be used for data encryption and decryption. The Triple DES (3DES) algorithm can 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 unique identifiable information for each entity requiring the key.

[0105] Regarding master key management, for each part of an asset portfolio issuing 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 as card master keys 708 and 720, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 722 and Derived Key Index (pDKI) 724, which are background data, can be used to identify which issuer master keys 702 and 726 are used in 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.

[0106] In some examples, to improve the security of the solution, session keys (such as a unique key for each session) can be derived. However, as explained above, a unique card-derived key and a counter can be used to distribute 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 session keys 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. To fit data into one or more algorithms, only the lower 2 bytes of the 4-byte pATC 704 are used. 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.

[0107] As described in this article, the lower two bytes of the pATC 704 counter can be used to derive one or more MAC session keys. 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. The pATC 704 can be initialized to zero during personalization or applet initialization. In some examples, the pATC 704 counter can be initialized during or before personalization and can be configured to increment by one with each NDEF read.

[0108] Furthermore, each card update can be unique and can be assigned through personalized allocation or by algorithms using pUIDs or other identification information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, updates can also vary during sequential reads, allowing a card to increment repeatedly in the sequence 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence can be defined at personalized times 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.

[0109] 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 may consist only of authentication data, an 8-byte random number, and a subsequent MAC of the authentication data. In some examples, the random number may precede the ciphertext A and can be a block length. In other examples, there may 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, an additional 8-byte block can be added to match the block generated by the MAC algorithm. As another example, if the algorithm used employs a 16-byte block, a multiple of the block size can be used, or the output can be automatically or manually padded to a multiple of that block size.

[0110] 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 to be associated with the EMV Authorization Request Ciphertext (ARQC) verification method. 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 a message.

[0111] 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 Chaining (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.

[0112] The following format represents an example embodiment of the binary version. Furthermore, in some examples, the first byte may be set to ASCII "A".

[0113]

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

[0115]

[0116] 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 key (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 find the shared secret of the contactless card. This shared secret, along with the message's Ver, UID, and pATC fields, can be processed via cryptographic MAC using a recreated Aut-Session-Key to create a MAC output, such as 'MAC'. If 'MAC' matches the ciphertext A714, this indicates that both message decryption and the MAC check have passed. The pATC can then be read to determine its validity.

[0117] During the 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, via one or more session keys (such as AUT-Session-Key 732) and Method 2 padding. The input data 706 can take the form of: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses can include a length in bytes. In some examples, the shared secret can be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more security processes. In some examples, the shared secret can 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 can include adding a mandatory 0x'80' byte to the end of the input data, and 0x'00' bytes that can be added to the end of the resulting data up to an 8-byte boundary. The length of the resulting ciphertext can include 8 bytes.

[0118] In some examples, one advantage of encrypting the first block with the MAC ciphertext using a non-shared random number 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 fixed or dynamic IVs.

[0119] By including the Application Transaction Counter (pATC) as part of the data 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 becomes 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 less 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 the pATC is greater than a previously received value, it can be evaluated to determine if it is within an acceptable range or threshold, and if it exceeds or falls outside the range or threshold, the authentication can be considered failed or unreliable. In MAC operation 712, data 706 is processed via MAC using the AUT-Session-Key 732 to produce a MAC output (ciphertext A) 714, which is encrypted.

[0120] To provide additional protection against brute-force attacks on the key on the exposure card, it is best 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), and 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 can be configured to ensure 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, namely ciphertext B 718. The MAC output (ciphertext A) 714 may be encrypted using 3DES in cipher block chaining mode to ensure that an attacker must attack all ciphertext. As a non-limiting example, other algorithms such as Advanced Encryption Standard (AES) may 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.

[0121] In order for 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; pUID used to retrieve the encrypted asset and derive the card key; and pATC used to derive the session key for the ciphertext.

[0122] Figure 8 A method 800 for generating ciphertext is illustrated. For example, at box 802, the Network Profile Record ID (pNPR) and Derived Key Index (pDKI) can 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 contactless card's pNPR and pDKI during authentication.

[0123] At box 804, the issuer master key can be distributed by combining the cardholder master key with the card’s unique ID number (pUID) and the personal area network (PAN) serial number (PSN) of one or more mini-programs (e.g., payment mini-programs).

[0124] At box 806, Card-Key-Auth and Card-Key-DEK (unique card key) can be created by distributing the issuer master key to generate a session key that can be used to generate MAC ciphertext.

[0125] At box 808, the key used to generate ciphertext and encrypt data in one or more applets may include the session keys from block 806 based on the card-unique keys (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.

[0126] Figure 9 An exemplary process 900 for key distribution is depicted 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 can be updated at box 902, as well as other data (such as data to be protected), which can be securely shared with the receiver.

[0127] At box 904, the counter value can be encrypted by the sender using the data encryption master key to generate a data encryption-derived session key, and the counter value can 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 can be used during both encryption processes.

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

[0129] At box 906, the data to be protected is cryptographically MAC-operated by the sender using a 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).

[0130] At box 908, the data to be protected can be encrypted by the sender using a session key derived from the data encryption, combined 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).

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

[0132] At box 912, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as explained above.

[0133] At box 914, the session key derived from the data encryption is 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 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.

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

[0135] 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 considered correct if decryption is successful and a correct MAC value is generated. Successful decryption indicates that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the transmitting device) and the receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed authentic. 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.

[0136] After this, 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.

[0137] Figure 10 A method 800 for card activation according to an example embodiment is illustrated. 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.

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

[0139] In box 1004, one or more portions of dynamically generated data can be transmitted to the device's application via NFC or other wireless communications. For example, tapping a card near the device can allow the device's application 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 can 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 can 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, or close to or near the surface of the device. In response to the card's gesture, placement, and / or orientation, the device can continue transmitting one or more encrypted portions of the data received from the card to one or more servers.

[0140] In box 1006, one or more portions of the data can be transmitted 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 card issuer server for card activation.

[0141] In box 1008, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and may 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 may 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 may be performed. For example, in response to a determination of a failed match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold, including the number of attempts allowed to allow the user 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 an associated service to assist in activating the card; or receive another notification, such as a telephone call on his or her device indicating that the card verification attempt was unsuccessful, and call, email, or text message to an 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 an associated service to assist in activating the card.

[0142] In box 1010, one or more servers can transmit a return message based on successful card activation. 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, it 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, and one or more servers will receive a notification that the card has been activated.

[0143] Figures 1 to 10This typically involves systems and methods for authenticating contactless cards based on information on the card. However, as previously described, some embodiments disclosed herein may include systems and methods for enhancing the security of logging into mobile applications on mobile devices. For example, in some embodiments, a multi-pronged security protocol may be implemented to ensure that a predetermined number of security measures are met before allowing a user to log into a mobile application. In some embodiments, such security measures may include verifying ciphertext received by the mobile device from the contactless card to identify a customer account associated with the contactless card, verifying that the mobile device's phone number is associated with the customer account, and verifying that enhanced security input data received by the mobile device matches enhanced security record data associated with the customer account. Figures 11 to 14 These embodiments are typically addressed, and additional details thereof are provided.

[0144] Figure 11 This 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.

[0145] As shown in the figure, 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 that are 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.

[0146] In some embodiments, 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 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, interface 1104 may include a WiFi interface, a Bluetooth interface, an NFC interface, a serial bus interface, and a Universal Serial Bus (USB), etc.

[0147] 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.

[0148] In some embodiments, the 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.

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

[0150] 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 processors, spreadsheets, etc.), store 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.

[0151] 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, or a Windows Mobile® operating system. Operating system 1110 may be configured to provide services and instructions that 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.

[0152] Figure 12This is a block diagram illustrating an example of a system 1200 according to a disclosed embodiment. As shown, system 1200 may include a mobile device 1202 and a contactless card 1204. It should be understood that mobile device 1202 may be the same as or similar to mobile device 1102 and / or client device 104. It should also be understood that contactless card 1204 may be the same as or similar to contactless card 102. Contactless card 1204 may be associated with a customer account of the bank or company that issued the contactless card 1204, and the telephone number of mobile device 1202 may also be associated with the customer account.

[0153] In some embodiments, a user may tap or otherwise bring the contactless card 1204 into the communication range of the mobile device, and the mobile device 1202 may read ciphertext from the contactless card 1204 and / or the contactless card 1204 may transmit ciphertext to the mobile device 1202. In operation, the mobile device 1202 and / or a server communicating with the mobile device 1202 may verify the ciphertext to identify the customer account associated with the contactless card 1204. For example, in some embodiments, the mobile device 1202 may successfully decrypt the ciphertext to identify the customer account associated with the contactless card 1204. Specifically, in some embodiments, the mobile device 1202 may decrypt 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 may identify the associated customer account. However, in some embodiments, the mobile device 1202 can transmit the ciphertext to a server to verify the ciphertext and identify the customer account associated with the contactless card 1204, for example, as... Figures 1 to 10 The discussion focuses on this. 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 associated customer account.

[0154] Once the encrypted message has been verified and the customer account associated with the contactless card 1204 has been identified, the mobile device 1202 and / or the server can verify that the mobile device's phone number is associated with the customer account. For example, in some embodiments, the mobile device 1202 and / or the server can call or otherwise contact or connect to a mobile network operator to identify the mobile device's phone number. In these embodiments, the mobile device 1202 and / or the server can contact a backend mobile network operator to request the phone number associated with the mobile device, thereby performing silent mobile authentication. However, in some embodiments, the mobile device 1202 can transmit its phone number to a server to verify whether the phone number in the mobile device 1202 is associated with a customer account. In these embodiments, silent mobile authentication may include the mobile application, the 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 in the mobile device 1202 matches data maintained by the mobile network operator. For example, a mobile application, mobile device 1202, and / or a server can transmit the mobile device's phone number to a mobile network operator, who can then search its data (e.g., data storage, databases, etc.) to determine if a match has been identified. When the mobile network operator matches the phone number of mobile device 1202 against data maintained by that operator, it can transmit a verification message to the mobile application, mobile device 1202, and / or the server.

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

[0156] Once the encrypted message has been verified, the customer account associated with the contactless card 1204 has been identified, and the phone number of the mobile device 1202 has been verified as associated with the customer account, the mobile device 1202 can display a request for enhanced security input data and receive the enhanced security input data. The mobile device 1202 and / or the server can verify whether the enhanced security input data matches enhanced security record data associated with the customer account. For example, in some embodiments, the mobile device 1202 can compare the enhanced security input data with enhanced security record data associated with the customer account and stored on the mobile device 1202 and / or the server to determine if a match exists. However, in some embodiments, the mobile device can transmit the enhanced security input data to the server to verify that the enhanced security input data matches enhanced security record data associated with the customer account and stored on the server. When the enhanced security input data has been verified, the mobile device 1202 can log in to a mobile application running thereon to access the customer account.

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

[0158] Figure 13This 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, a server communicating with the mobile device may perform some or all of method 1300.

[0159] As shown, method 1300 may include receiving ciphertext from a contactless card, as shown in 1302. For example, in some embodiments, a short-range communication antenna of a mobile device may receive ciphertext from a contactless card.

[0160] After receiving the ciphertext as in 1302, method 1300 may include verifying the ciphertext as in 1304 to identify a customer account associated with the contactless card. For example, in some embodiments, the processor of the mobile device and / or server may verify the ciphertext and / or identify the customer account associated with the contactless card. In some embodiments, the processor of the mobile device and / or server may successfully decrypt the ciphertext to verify the ciphertext and / or identify the customer account associated with the contactless card. For example, the processor of the mobile device and / or server may decrypt protected data in the ciphertext, compare the protected data with recorded data associated with the contactless card and stored on the mobile device and / or server, and identify the customer 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 customer account associated with the contactless card, the interface of the mobile device may transmit the ciphertext to the server and receive one or more indications indicating that the ciphertext has been verified and / or the customer account associated with the contactless card has been identified. For example, a mobile device can transmit one or more data messages, including ciphertext, to a server, and can receive indications, including a customer account identifier associated with the contactless card and / or that the ciphertext has been verified.

[0161] After the encrypted data has been verified and the customer account associated with the contactless card has been identified (as shown in 1304), method 1300 may include verifying that the mobile device's phone number is associated with the customer account (as shown in 1306). For example, the processor of the mobile device and / or the server may identify the mobile device's phone number and compare it with a recorded number associated with the customer account and stored on the mobile device and / or the server to determine if they match, thereby verifying that the mobile device's phone number is associated with the customer account. In some embodiments, the interface of the mobile device and / or the server may 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 embodiments where the server verifies that the mobile device's phone number is associated with the customer account, the mobile device's interface may transmit identification data to the server and may receive one or more indications indicating that the recorded number associated with the customer account and / or the mobile device's phone number has been verified as associated with the customer account.

[0162] After the encrypted message has been verified, the customer account associated with the contactless card has been identified, and the mobile device's phone number has been verified as associated with the customer account, method 1300 may include receiving enhanced security input data, as shown in 1308. In some embodiments, in response to the mobile device's processor verifying that the mobile device's phone number is associated with the customer account, the mobile device's display device may display a request for enhanced security input data.

[0163] In response to receiving enhanced security input data, method 1300 may include verifying that the enhanced security input data matches security record data associated with a customer account, as shown in 1310. For example, a processor of a mobile device and / or server may compare the enhanced security input data with security record data associated with a customer account and stored on the mobile device and / or server, and determine whether a match exists between them. In an embodiment where the server verifies that the enhanced security input data matches the security record data associated with the customer account, the interface of the mobile device may transmit the enhanced security input data to the server and receive one or more indications as to whether the enhanced security input data matches the security record data associated with the customer account. For example, the mobile device may transmit one or more data messages including the enhanced security input data to the server and may receive one or more indication messages including indications that the enhanced security input data has been verified as matching the security record data associated with the customer account.

[0164] Finally, method 1300 may include logging into a mobile application on a mobile device to access a customer account, as shown in 1312. For example, the processor of the mobile application, the mobile device, and / or the server may provide access to the customer account via the mobile application running on the mobile device.

[0165] Figure 14 An example of a sequence flow 1400 according to a disclosed embodiment is shown. In some embodiments, verification and / or authentication may be performed by a mobile device 1404. Additionally or alternatively, in some embodiments, verification and / or authentication may be performed by a server 1406.

[0166] At 1408, the contactless card 1402 can be tapped or brought into the communication range of the mobile device 1404 and can exchange information with the mobile device 1404. Line 1408 may represent communication between the contactless card 1402 and the mobile device 1404 and may include ciphertext stored on the contactless card 1402 and provided to the 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... Figures 1 to 10 As shown.

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

[0168] Mobile device 1404 can process ciphertext received from contactless card 1402. For example, in some embodiments, mobile device 1404 and / or server 1406 can verify the ciphertext to identify a customer account associated with contactless card 1402. In some embodiments, mobile device 1404 can operate as a channel, transmitting ciphertext and other data to server 1406 for verification and authentication, for example, as... Figures 1 to 10 The subject of discussion.

[0169] like Figure 14As shown, at 1410, mobile device 1404 can transmit information to server 1406, and at 1412, server 1406 can transmit information to mobile device 1404. Line 1410 can represent communication from mobile device 1404 to server 1406, and line 1412 can represent communication from server 1406 to mobile device 1404. For example, in some embodiments, mobile device 1404 can transmit ciphertext received from contactless card 1402 to server 1406, and server 1406 can transmit to mobile device 1404 an indication that the ciphertext has been verified and / or the customer account associated with contactless card 1402 has been identified. However, in some embodiments, mobile device 1404 can partially or completely process the ciphertext received from contactless card 1402 and transmit the processed ciphertext to server 1406, such as partially or completely decrypted protected data or keys. Additionally or alternatively, in some embodiments, mobile device 1404 may transmit an information request to server 1406 requesting data stored on server 1406, such as recorded data, for comparison with protected data in ciphertext received from contactless card 1402, and server 1406 may transmit such requested data to mobile device 1404. Additionally or alternatively, in some embodiments, the information request transmitted from mobile device 1404 to the server may request the identifier of a customer account associated with contactless card 1402 and / or data associated therewith, and server 1406 may transmit such requested data to 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 customer account and / or data associated therewith for comparison with data associated with mobile device 1404 (including the telephone number of mobile device 1404).

[0170] Mobile device 1404 and / or server 1406 can also verify whether the phone number on mobile device 1404 is associated with a customer account. For example... Figure 14As shown, at 1414, mobile device 1404 can transmit information to server 1406, and at 1416, server 1406 can transmit information to mobile device 1404. Line 1414 can represent communication from mobile device 1404 to server 1406, and line 1416 can represent communication from server 1406 to mobile device 1404. For example, in some embodiments, mobile device 1404 can transmit its phone number to server 1406, and server 1406 can transmit an indication to mobile device 1404 that the phone number of mobile device 1404 is associated with a customer account. Additionally or alternatively, in some embodiments, mobile device 1404 and / or server 1406 can call or otherwise contact or connect to a mobile network operator to verify whether the mobile device's phone number matches mobile network operation 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, for comparison with the mobile device's telephone number, and server 1406 may transmit such requested data to mobile device 1404. In some embodiments, mobile device 1404 may store a recorded number thereon for comparison with the mobile device 1404's telephone number.

[0171] At 1418, mobile device 1404 can receive enhanced security input data as user input. Line 1418 can represent communication from the user to mobile device 1404. For example, the enhanced security input data can be input into the display device of mobile device 1404. Mobile device 1404 and / or server 1406 can then verify whether the enhanced security input data matches enhanced security record data associated with the customer account. In some embodiments, mobile device 1404 can operate as a channel and transmit enhanced security input data to server 1406 for verification.

[0172] Mobile device 1404 and / or server 1406 can also verify whether the phone number on mobile device 1404 is associated with a customer account. For example... Figure 14As shown, at 1420, mobile device 1404 can transmit information to server 1406, and at 1422, server 1406 can transmit information to mobile device 1404. Line 1420 can represent communication from mobile device 1404 to server 1406, and line 1422 can represent communication from server 1406 to mobile device 1404. For example, in some embodiments, mobile device 1404 can transmit received enhanced security input data to server 1406, and server 1406 can transmit an indication to mobile device 1404 that the enhanced security input data matches enhanced security record data associated with a customer account. Additionally or alternatively, in some embodiments, mobile device 1404 can transmit an information request to server 1406 requesting enhanced security records stored on server 1406 for comparison with enhanced security input data, and server 1406 can transmit the requested data to mobile device 1404. In some embodiments, mobile device 1404 can store enhanced security record data thereon for comparison with enhanced security input data.

[0173] It should be understood that server 1406 may process, partially or completely, 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.

[0174] 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.

[0175] At 1424, after verifying that the enhanced security input data matches the enhanced security record data associated with the customer account, the mobile device 1404 can log in to the mobile application running on the mobile device 1404 to access the customer account. In some embodiments, logging in to the mobile application may include communication between the mobile device 1404 and the server 1406 as described herein.

[0176] Figure 15An embodiment of an exemplary computer architecture 1500 suitable for implementing the various embodiments described above is illustrated. In one embodiment, the computer architecture 1500 may include or be implemented as part of one or more systems or devices discussed herein.

[0177] 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 can 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 can both be components. One or more components may reside in a process and / or an execution thread, and components may be localized on a single computer and / or distributed across two or more computers. Furthermore, components can communicatively 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, a component may convey information in the form of transmitted signals via a communication medium. This information can 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.

[0178] The computing architecture 1500 includes a variety of 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. However, these embodiments are not limited to those implemented by the computing architecture 1500.

[0179] like Figure 15 As shown, the computing architecture 1500 includes a processor 1512, system memory 1504, and system bus 1506. The processor 1512 can be any of a variety of commercial processors.

[0180] System bus 1506 provides interfaces for system components, including but not limited to system memory 1504 to processor 1512. System bus 1506 can be any of several types of bus architectures that can be further interconnected to memory buses (with or without memory controllers), peripheral buses, and local buses using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 1506 via slot architectures. Example slot architectures can 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, PCMCIA, and similar architectures.

[0181] The 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. Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium that can be read and executed by one or more processors to perform the operations described herein.

[0182] 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 storage devices (e.g., USB storage), solid-state drives (SSDs), and any other type of storage media suitable for storing information. Figure 15In the illustrated embodiment, 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.

[0183] 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.

[0184] The drive and associated computer-readable medium provide volatile and / or non-volatile storage devices for data, data structures, and computer-executable instructions, etc. For example, numerous program modules may be stored in the drive and non-volatile memory 1508 and volatile memory 1510, including an 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, such as those of the systems discussed herein.

[0185] Users can input commands and information to computer 1502 through one or more wired / wireless input devices, such as keyboard 1550 and pointing devices such as mouse 1552. 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 processor 1512 via input device interface 1536 coupled to system bus 1506, but can be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, and IR interfaces.

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

[0187] 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. The one or more remote computers 1548 can 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 local area networks 1556 and / or larger networks (such as wide area networks 1554). Such LAN and 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).

[0188] When used in a networked environment of LAN 1556, computer 1502 connects to LAN 1556 via a wired and / or wireless communication network interface or network adapter 1538. Network adapter 1538 facilitates wired and / or wireless communication with LAN 1556, which may also include a wireless access point configured thereon for communicating with the wireless functionality of network adapter 1538.

[0189] When used in a wide area network (WAN) 1554 networking environment, computer 1502 may include modem 1540, or a communication server connected to WAN 1554, or have other means for establishing communication on WAN 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 networking environment, 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.

[0190] 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 can be a predefined structure like a regular 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).

[0191] The various elements of the device described earlier herein can include a variety of hardware elements, software elements, or combinations thereof. Examples of hardware elements can 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 can 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 elements and / or software elements can vary depending on many factors, such as desired computational speed, power levels, thermal tolerance, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints required for a given implementation.

[0192] The components and features of the aforementioned devices can be implemented using any combination of discrete circuits, ASICs, logic gates, and / or monolithic architectures. Furthermore, where appropriate, the features of the devices 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 or individually referred to herein as "logic" or "circuit".

[0193] Figure 16This 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.

[0194] like Figure 16 As shown, the communication architecture 1600 includes one or more clients 1602 and one or more servers 1604. The one or more servers 1604 may implement one or more of the functions and embodiments discussed herein. The 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 the one or more corresponding clients 1602 and one or more servers 1604, such as cookies and / or associated contextual information.

[0195] One or more clients 1602 and one or more servers 1604 can use the communication framework 1610 to communicate with each other. The communication framework 1610 can implement any well-known communication technology and protocol. The communication framework 1610 can 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).

[0196] The communication framework 1610 can implement various network interfaces arranged to receive, communicate, and connect to a communication network. A network interface can be considered a special form of input / output (I / O) interface. Network interfaces can 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 interfaces, cellular network interfaces, IEEE 802.7ax network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, 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 specify greater speed and capacity, a similar distributed network controller architecture can be used 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.

Claims

1. A method, the method comprising: Receive encrypted messages from contactless cards via the short-range communication antenna of the mobile device; The encrypted message is verified by the processor of the mobile device to identify the customer account associated with the contactless card; The mobile device's processor verifies that the mobile device's phone number is associated with the customer's account; as well as Enhanced security input data is received via the user interface of the mobile device; The enhanced security input data is verified by the mobile device's processor to match the enhanced security record data associated with the customer account; as well as Once the encrypted message, the mobile device's phone number, and the enhanced security input data have been verified, log in to the mobile application running on the mobile device to access the customer account.

2. The method according to claim 1, wherein, The enhanced security input data includes alphanumeric passwords.

3. The method according to claim 1, wherein, The user interface device includes a camera on the mobile device, and the enhanced security input data includes selfies of the user captured by the camera during a predetermined time period during which the short-range communication antenna receives the ciphertext from the contactless card.

4. The method according to claim 1, wherein, The enhanced security input data includes biometric input data.

5. The method according to claim 1, further comprising: In response to verifying the ciphertext and the mobile device's phone number, a request for the enhanced security input data is displayed on the mobile device's display device.

6. The method according to claim 1, further comprising: The ciphertext was successfully decrypted to verify it and identify the customer account.

7. The method according to claim 6, further comprising: Decrypt the protected data in the ciphertext; The protected data is compared with the recorded data stored in the contactless card; as well as The customer account is identified based on the matching between the protected data and the stored record data.

8. The method according to claim 1, further comprising: The ciphertext and the enhanced security input data are transmitted from the mobile device to the server; as well as The encrypted message, the mobile device's phone number, and one or more indications that the enhanced security input data has been verified are received at the mobile device.

9. The method according to claim 8, further comprising: One or more messages are transmitted from the mobile device to the server, wherein the one or more messages include the ciphertext and the enhanced security input data.

10. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the following operations: Receive encrypted messages from contactless cards via the short-range communication antenna of the mobile device; Verify the encrypted message to identify the customer account associated with the contactless card; Verify that the phone number on the mobile device is associated with the customer account; as well as Enhanced security input data is received via the user interface device of the mobile device; Verify that the enhanced security input data matches the enhanced security record data associated with the customer account; as well as Once the encrypted message, the mobile device's phone number, and the enhanced security input data have been verified, log in to the mobile application running on the mobile device to access the customer account.

11. The non-transitory computer-readable medium according to claim 10, wherein, The enhanced security input data includes alphanumeric passwords.

12. The non-transitory computer-readable medium according to claim 10, wherein, The user interface device includes a camera, and the enhanced security input data includes selfies of the user captured by the camera during a predetermined time period during which the short-range communication antenna receives the ciphertext from the contactless card.

13. The non-transitory computer-readable medium according to claim 10, wherein, The enhanced security input data includes biometric input data.

14. The non-transitory computer-readable medium according to claim 10, wherein, In response to verifying the ciphertext and the mobile device's phone number, the instruction also causes the processor to display a request for the enhanced security input data on the mobile device's display device.

15. The non-transitory computer-readable medium according to claim 10, wherein, The instruction also causes the processor to successfully decrypt the ciphertext in order to verify the ciphertext and identify the customer account.

16. The non-transitory computer-readable medium according to claim 15, wherein, The instruction causes the processor to perform the following further operations: Decrypt the protected data in the ciphertext; The protected data is compared with the recorded data stored associated with the contactless card; and The customer account is identified based on the matching between the protected data and the stored record data.

17. The non-transitory computer-readable medium according to claim 15, wherein, The instruction causes the processor to perform the following further operations: The ciphertext and the enhanced security input data are transmitted to the server; and The system receives one or more indications that the encrypted message, the mobile device's phone number, and the enhanced security input data have been verified.

18. The non-transitory computer-readable medium according to claim 17, wherein, The instructions also cause the processor to transmit one or more messages to the server, wherein the one or more messages include the ciphertext and the enhanced security input data.

19. A mobile device, the mobile device comprising: Short-range communication antenna; User interface devices; processor; and The memory stores instructions that, when executed by the processor, cause the processor to perform the following operations: The encrypted message from the contactless card is received via the short-range communication antenna. Verify the encrypted message to identify the customer account associated with the contactless card; Verify that the phone number on the mobile device is associated with the customer account; as well as Receive enhanced security input data via the user interface device; Verify that the enhanced security input data matches the enhanced security record data associated with the customer account; as well as Once the encrypted message, the mobile device's phone number, and the enhanced security input data have been verified, log in to the mobile application running on the mobile device to access the customer account.

20. The mobile device of claim 19, further comprising: Display devices In response to verifying the ciphertext and the mobile device's phone number, the instruction also causes the processor to display a request for the enhanced security input data on the display device.

Images