Techniques for performing dynamic call center authentication using contactless cards

Abstract

Techniques and systems for performing authentication using mini applications.

Description

Background Art

[0001] Service providers often offer call center services that enable customers to access, modify, delete, or otherwise control their accounts. From a security perspective, call centers can be the riskiest area for an enterprise, as call center transactions can expose sensitive customer information to malicious third parties.

[0002] Call centers face both internal and external risks. Internal risks include employees stealing sensitive customer information. During a typical authentication process, call center employees have direct access to sensitive customer data. Call centers may be outsourced, and call center employees have a high turnover rate. Therefore, companies are constantly at risk that departing or remote employees may inappropriately retain customer information.

[0003] External risks include those posed by “spoofing” and “phishing,” where an imposter masks or modifies the calling number, email address, IP address, etc., to impersonate a customer in an attempt to steal information or funds. There is also an external risk from hackers monitoring the communications of service providers, particularly call centers, to steal customer information.

[0004] The Payment Card Industry Security Standards Council (PCI SSC) manages the ongoing development of the Payment Card Industry (PCI) security standards to address these security concerns. Service providers are responsible for enforcing compliance with PCI standards to protect sensitive customer data. For example, PCI standards may specify authentication criteria to be followed before a client is allowed to access and / or modify customer account information. Call centers may require client authentication in the form of password exchange, answering personal questions, biometric data, etc. During the processing of a call, the customer may be prompted multiple times to provide authentication information in various forms. Not only can this authentication and re-authentication process frustrate the client and reduce the reputation of the service provider, each instance of authentication may expose sensitive customer information to potentially malicious parties. Summary of the invention

[0005] In one aspect, an embodiment includes a computer-implemented method comprising: establishing, by a call center system, a call connection with a mobile device; determining, by the call center system, a call session identifier of the call connection and a telephone number associated with the mobile device; sending, by the call center system, a text message to the mobile device based on the telephone number, the text message including the call session identifier and a mini-application link, the mini-application link being configured to be retrieved by the mobile device from a server as a code snippet; receiving, by the call center system, authentication information and the call session identifier from the mobile device, the authentication information being generated by a contactless card; determining, by the call center system that the authentication information is authentic; and enabling, by the call center system, the call connection to continue communication.

[0006] In one aspect, a call center system includes a processing circuit. The call center system also includes a memory storing instructions that, when executed by the processing system, cause the system to determine a call connection with a mobile device, determine a telephone number associated with the mobile device, send a text message to the mobile device based on the telephone number, the text message including a mini-app link, the mini-app link configured to retrieve a code snippet on the mobile device, receive authentication information from the mobile device, the authentication information generated by a contactless card, authenticate the authentication information, and enable the call connection to proceed with communication based on the authentication information being authentic.

[0007] In one aspect, an embodiment system and device for performing computer-implemented methods and techniques includes a computer-implemented method having: establishing a call connection with a call center system by a mobile device, receiving a text message including a call session identifier and a mini-application link by the mobile device, the mini-application link being configured to retrieve a code snippet from a server, receiving the code snippet from the server by the mobile device, executing the code snippet by the mobile device, the code snippet causing a prompt to tap a contactless card on or near the mobile device to be presented on a display of the mobile device, tapping the contactless card on or near the mobile device based on the snippet, receiving authentication information from the contactless card, sending the authentication information and the call session identifier by the mobile device, and maintaining the call connection with the call center system by the mobile device based on an indication that the authentication information is authenticated. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To facilitate identification of the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the drawing number in which the element is first introduced.

[0009] Figure 1 An example of a system 100 according to an embodiment is shown.

[0010] Figure 2A An example of a sequence diagram 200a that may be performed according to an embodiment is shown.

[0011] Figure 2B An example of a sequence diagram 200b that may be performed according to an embodiment is shown.

[0012] Figure 3 A routine 300 is shown according to an embodiment.

[0013] Figure 4 A routine 400 is shown according to an embodiment.

[0014] Figure 5 A process flow 500 is shown according to an embodiment.

[0015] Figure 6An example of a system 600 is shown according to an embodiment.

[0016] Figure 7 A contactless card 116 is shown according to one embodiment.

[0017] Figure 8 A transaction card component 800 is shown according to one embodiment.

[0018] Fig. 9 A sequence flow 900 is shown according to one embodiment.

[0019] Fig.10 A data structure 1000 is shown according to one embodiment.

[0020] Fig.11 is a diagram of a key system according to an example embodiment.

[0021] Fig.12 is a flow chart of a method of generating a password according to an example embodiment.

[0022] Fig.13 An aspect of the subject matter according to one embodiment is shown.

[0023] Fig.14 An aspect of the subject matter according to one embodiment is shown.

[0024] Fig.15 Computer architecture 1500 is shown according to one embodiment.

[0025] Fig.16 A communications architecture 1600 is shown according to one embodiment. DETAILED DESCRIPTION

[0026] Embodiments generally relate to systems and techniques for performing secure authentication operations using mini-applications operating client devices, such as their mobile devices or mobile phones. Thus, these techniques enable secure authentication operations to be performed via the device without downloading large full applications, and improve upon previous technical solutions by minimizing the download time and storage space required for the application.

[0027] For example, a customer may need to be authenticated during a help or customer service call. The technology discussed herein includes sending a text message including a link to a mini-app to a device associated with the customer. The mini-app is downloaded and executed on the customer's device to perform the authentication. As discussed, the mini-app may include a minimal amount of executable instructions to perform the authentication. In one example, the customer's contactless card may be used for authentication. The customer may be asked to bring the card into the communication range of the device, for example, by tapping the card on the device, which initiates a data exchange between the device and the contactless card. As part of the exchange, the card may send and / or the device may retrieve authentication information. The device may send the authentication information to the system to perform the customer's authentication. Based on the results of the authentication, the call may be allowed to continue or may be canceled. These and other details will become more apparent in the description below.

[0028] Figure 1 An example of a system 100 is shown in accordance with embodiments discussed herein. The illustrated system 100 is a simplified illustration for discussion purposes, and in implementations, the system 100 includes additional components not shown, such as network components, additional servers and processing devices, and the like.

[0029] The illustrated system 100 includes components and devices for executing and processing call center communications and simplifies and rapidly authenticates callers to a call center as compared to conventional authentication techniques. As previously mentioned, the embodiments discussed herein provide advantages over conventional systems by enabling customers to call into a call center and authenticate them using their contactless card without having to install a full mobile application on a mobile device or another client device.

[0030] The call center system 106 may be configured to provide call center services that offer products or services to callers. In one example, the call center system 106 may be implemented as part of a banking system and configured to provide call center services to customers of the bank. Thus, in some cases, the call center system may handle sensitive information, requiring callers to be authenticated before the information is discussed. The call center system 106 may include any number of components to enable multiple operators or call agents to handle calls and provide call center support. Figure 1 In the embodiment, the call center system 106 includes a call server 108 and an authentication server 110. The call server 108 can be configured to provide call center services, including processing calls and establishing call connections with other devices, providing a user interface for support personnel and operators, accessing information and data to support calls, determining that customer authentication is required, initiating authentication operations, etc. It should be noted that the call server 108 can be multiple servers and other computing devices and equipment.

[0031] The authentication server 110 may perform authentication operations on the call center system 106. In this embodiment, the authentication server 110 may include multiple servers and other computing devices and components. The authentication server 110 may be configured to register pending authentication operations and perform authentication operations by comparing authentication information provided by the caller with authenticated information maintained by the authentication server 110 (e.g., in a data store). The authentication server 110 may return the results of the authentication operation to the call server 108 to determine whether to proceed with the call.

[0032] In an embodiment, the call center system 106 is configured to receive telephone calls from any type of telephone device, such as the mobile device 102, the phone 118, or any other device for making calls. In addition, the call center system 106 can be configured to receive and process calls according to different protocols, such as protocols required to receive calls on a plain old telephone system (POT 120) and a Voice over Internet Protocol (VoIP) system via the network 104, which can include cellular communication protocols and landline telephone protocols.

[0033] In one specific example, a call center system 106 including a call server 108 can receive or initiate a call with a device and establish a call connection with the device. Once established, the call server 108 can determine that an authentication routine or operation is required to support the call. For example, the call can handle secure information, such as a bank account. The call server 108 can initiate an authentication routine to register a pending authentication with the authentication server 110 and authenticate the caller or user on the phone.

[0034] The authentication server 110 can perform authentication operations, including collecting information from the caller. As described herein, the call center system 106 including the authentication server 110 can utilize a mini application or code snippet (such as App or Instant ) to perform the authentication routine and collect authentication information from the caller. Utilizing a mini-application or code snippet provides an improvement over conventional techniques because it enables the call center system 106 to securely and electronically collect data from the caller without requiring the caller to install a bulky application that may take a long time. The mini-application or code snippet is specifically customized to perform the operations of collecting authentication information and provides further processing to the information authentication server 110.

[0035] In order to provide the mini-application or code snippet to the customer, the call center system 106 including the call server 108 can register the authentication operation with the authentication server 110 to notify the authentication server 110 of the pending authentication and generate a call session identifier associated with the authentication operation. Specifically, the call server can make an application programming interface (API) call to the authentication server to associate the caller's unique identifier (e.g., a portable unique identifier (pUID)) with the pending authentication to be performed by the authentication server. The authentication server can generate a session token or a call session identifier for the pending authentication and return the call session identifier to the call server in response to the API call. The call session identifier can be provided in a text message sent to the mobile device. The call session identifier can be any unique combination of alphanumeric characters used to uniquely identify the pending authentication operation of the authentication server 110. The call session identifier can be a one-time use identifier, and each pending authentication operation can be associated with a different identifier.

[0036] The call server 108 may generate a text message including a link to download and / or launch the mini-app on a device associated with the caller. The text message may be communicated according to any message protocol, such as a short message service (SMS), a multimedia message service (MMS), and a rich communication service (RCS), etc. The link may be a uniform resource locator (URL) link to a location to download the mini-app, such as an address of a server. In some embodiments, the link may point to a server 114 of an application store system 112, and the device may download the mini-app or code snippet from the application store system 112. In other cases, the call center system 106 may maintain the mini-app, and the user's device may download it from the call center system 106.

[0037] The call server 108 can send the text message to a device associated with the caller. In some cases, the call server 108 can send it to the device that the caller is calling, such as the mobile device 102. However, in other cases, the calling device may not have text messaging capabilities, such as the phone 118, and the call server 108 can determine another device associated with the caller (such as a different mobile device or another computing device) to send the text message. In order to determine the device that sends the message, the call server 108 can use the phone number associated with the call connection. For example, the call server 108 can determine the call number associated with the call connection of the mobile device 102 and send the text message to the mobile device 102. In another example, the call center system 106 can perform a search using the call number associated with the call connection of the phone 118 to determine the different devices that send the text message. In an embodiment, other information can be used to determine the device that sends the message, for example, the caller can provide information such as their name, address, account number, etc.

[0038] In an embodiment, a device such as mobile device 102 may receive a text message from call server 108 to perform authentication. The text message includes a user-selectable link. For example, the caller may select the link using a touch screen interface or other input device. The messaging program may be configured to process the link, for example, launch an application to download a mini-app, automatically download a mini-app, or launch a mini-app.

[0039] In some cases, the text message may also include a call session identifier. The call session identifier may be attached to a portion of the text message. In some cases, it may be embedded in the link, and in other cases, it may be separate from the link. In some embodiments, the device may receive the call session identifier in a different text message. The call session identifier may be a unique identifier associated with the authentication operation and may be sent back to the authentication server 110 along with the authentication information to perform the authentication.

[0040] In an embodiment, the selectable link may include an address to a server, such as server 114 of application store system 112, to download a mini-app or code snippet configured to perform authentication. In response to being selected, mobile device 102 may automatically download and execute the mini-app. In some cases, mobile device 102 may have already downloaded the mini-app (e.g., from a previous authentication attempt), and selecting the link may cause the mini-app to execute.

[0041] Mini applications or code snippets can be configured to execute on mobile device 102 and include instructions to perform a single or limited number of operations. Typically, mini applications are much smaller in size than full-size applications, which is more beneficial than traditional solutions because it requires less memory to execute and can be downloaded faster.

[0042] According to an embodiment, the mini-application or code snippet discussed herein may include instructions to cause a prompt to be displayed on a display of a mobile device so that the user can provide a contactless card on or near the mobile device, and cause the mobile device to perform a wireless communication exchange (e.g., near field communication (NFC)) with the contactless card 116 to receive authentication information. The instructions may be configured to cause the mobile device 102 to communicate the authentication information and, in some cases, the call session identifier to the authentication server 110. The code snippet may be configured to utilize an application programming interface (API) provided by the authentication server 110, such as in an API call, to securely communicate the authentication information to the authentication server 110. In some cases, the mobile device 102 may also communicate the call session identifier to the authentication server 110 along with the authentication information. The authentication server 110 may associate the authentication information with a specific pending / registration and authentication routine. The mini-application or code snippet may include additional instructions capable of performing these operations, such as any files or runtime libraries required to perform the operations.

[0043] The authentication server 110 may process the authentication information to determine whether it is authentic. In an embodiment, the authentication server 110 may receive the authentication information and the call session identifier from the mobile device 102, determine the authentication information associated with the contactless card / caller, and compare the authentication information with the authenticated information to determine whether they match. In an embodiment, the authentication server 110 may use the call session identifier to determine the authenticated information associated with the contactless card or caller. For example, the authentication server 110 may perform a lookup based on the call session identifier to determine and retrieve the authenticated information from a data store. The data store may be any type of data store, such as a database configured to store authenticated information associated with a customer and his or her contactless card. In some cases, the call session identifier may be used to determine additional information associated with the caller to perform the lookup, such as an account number, name, and address, etc. This information may be associated with the call session identifier when registering the authentication operation.

[0044] In an embodiment, the authentication server 110 compares the authenticated information with the authentication information received from the mobile device 102. If they match, the authentication server 110 may authenticate the contactless card and notify the call server 108 and the operator. If they do not match, the authentication server 110 may not authenticate the contactless card and notify the call server 108 and the operator. In some cases, the authentication information may be encrypted, and the authentication server 110 may first decrypt the authentication information using a session key derived from a master key, as discussed herein, for example Figure 12 to Figure 14 In response to the authentication information being authenticated, 106 may enable the call to continue and maintain the call connection. If the authentication information is not authenticated, the call connection may be canceled or disconnected. Figures 6 to 14 Additional details regarding performing authentication using contactless card 116 and data on an authentication server are discussed.

[0045] In some embodiments, the caller can also perform an authentication operation to authenticate the operator of the call center system 106. In one example, the caller can send a text message with a code (e.g., an alphanumeric sequence) to the call center system 106. The code can be displayed to the operator, and the operator can read the code back. In an embodiment, the caller can send the text message to a known phone number associated with a known safe and / or legal call center system 106. If the operator is not authenticated, the caller can decide to end the call connection. Alternatively, if the operator is authenticated, the caller decides to keep the call connection.

[0046] Figure 2A and Figure 2B Example sequence flows 200a and 200b are shown that may be performed according to an embodiment to authenticate a caller by a call center. In addition to authenticating the caller, Figure 2B The sequence has also been expanded and includes authentication of the operator by the caller.

[0047] In an embodiment, a call may be initiated between the mobile device 102 and the call server 108 at line 202. The call may be initiated by the mobile device 102 or the call server 108, and the embodiment is not limited thereto. Initiating the call may include establishing a call connection between the mobile device 102 and the call server 108. Thus, the call may be made through a POT system, a VoIP system, or a combination thereof. Furthermore, the embodiment is not limited to calls using mobile devices, and calls may be made using older phones and / or non-mobile devices.

[0048] At line 204, the sequence includes the call server 108 sending a text message including the mini-app link to the call server 108. Although not shown in this manner, the call server 108 can also concurrently register a pending authentication for the call with the authentication server 110 at line 206. In some cases, the call server 108 can first register for authentication and receive a call session identifier included in the text message. In other cases, the call server 108 can send a second message with the call session identifier to the mobile device 102.

[0049] The registration authentication operation may include generating a call session identifier and determining authenticated information associated with the call. For example, the authentication server 110 may determine authenticated information based on information associated with the call (eg, phone number, caller name, account number, address, etc.).

[0050] At line 208, the sequence includes the mobile device 102 downloading the code snippet from the server 114 (e.g., an application store server). In an embodiment, the code snippet may be downloaded based on a user of the mobile device 102 selecting a mini-app link in a text message sent by the call server 108. The code snippet may be configured to execute on the mobile device 102 to perform an authentication operation. For example, the code snippet may cause a message to be displayed on the mobile device 102 to tap a contactless card to the mobile device 102. At line 210, the caller may tap a contactless card to the mobile device 102, and the mobile device 102 may receive authentication information from the card, as previously described. In addition, and at line 210, the mobile device also sends the authentication information to the authentication server 110. The mobile device 102 may send a call session identifier to the authentication server 110 along with the authentication information.

[0051] The authentication server 110 may perform an authentication operation on the authentication information. For example, the authentication server 110 may compare the authentication information with the authenticated information. If they match, the authentication server 110 may authenticate the authentication information; however, if they do not match, the authentication server 110 may not authenticate the authentication information. At line 212, the authentication server 110 may return the result of the authentication to the call server 108.

[0052] At line 214, the call connection is maintained between the mobile devices 102 and 108 based on the authenticated authentication information. If the authentication information is not authenticated, the call connection between the mobile device 102 and the call server 108 will end.

[0053] Sequence diagram 200b shows the same process as sequence diagram 200a; However, the caller can perform an authentication step to authenticate the operator. For example, at line 216, the caller and mobile device 102 can communicate a secret code to the call server 108. The call server 108 can present the secret code to the operator of the call server 108. The operator can read the code back through a voice connection, and the caller can confirm the operator's authentication. For example, at line 218, the mobile device 102 can send an indication of the result of the operator authentication server 114. Embodiments are not limited to the specific order shown in Figure 2a / Figure 2b. In some cases, one or more operations can occur before other operations.

[0054] Figure 3 An example routine 300 that can be performed by the systems discussed herein is shown. For example, a call center system including one or more servers can perform one or more of the following options. It should be noted that in some cases, one or more operations can be performed by different servers and / or systems. For example, a call server can process one or more operations for a call connection, while an authentication server can perform one or more operations to authenticate a caller. In other cases, the operations can be performed on a single server or computing device, or on multiple servers or computing devices.

[0055] In block 302, routine 300 includes establishing a call connection with a mobile device. For example, a call center system may establish a call connection with a mobile device based on the mobile device calling a helpline or contact number. In other cases, the call center system may initiate a call connection with the mobile device. The call connection may be made via any type of voice communication protocol or connection, such as plain old telephone service (POTS), cellular protocol, WiFi protocol, voice over Internet protocol (VoIP), etc.

[0056] In an embodiment, the call center system may first determine to perform one or more authentication operations to authenticate the caller using a mobile device. In box 304, routine 300 includes determining a call session identifier for the call connection and a telephone number associated with the mobile device. In order to determine the call session identifier, a call server of the call center system may communicate with an authentication server of the authentication system and register the call connection. Specifically, the call server may make an application programming interface (API) call to the authentication server to associate the caller's unique identifier (e.g., a portable unique identifier (pUID)) with a pending authentication to be performed by the authentication server. The authentication server may generate a session token or a call session identifier for the pending authentication and return the call session identifier to the call server in response to the API call. The authentication server may use the call session identifier to identify which pending authentication it is performing and where to return the authentication result.

[0057] The call center system can also determine the telephone number associated with the call connection. For example, the call center system can determine the telephone number based on information in the call itself. In another example, the call center system can perform a lookup of an account based on information provided by the caller. In a third example, the caller can provide a telephone number, for example, via voice input or touchpad input. The telephone number can be used to communicate with a mobile device.

[0058] For example, in block 306, the routine 300 includes sending a text message to the mobile device based on the phone number. The text message may include a call session identifier and a mini-app link. The mini-app link is configured to retrieve the code snippet from the server via the mobile device. In an embodiment, the mini-app link may be a uniform resource locator (URL) to a server address for downloading the mini-app. In some cases, the server may be part of an application store, such as Shop or App In other cases, the server may be part of a call center system, and embodiments are not limited in this regard.

[0059] In an embodiment, a mini-app can be a code snippet, such as a small portion of an executable code, that can be configured to execute on a mobile device. In some cases, a mini-app can be App or Instant However, the embodiments are not limited to these examples.

[0060] like Figure 4 As discussed in more detail in , the mobile device can download or retrieve the code snippet and execute the code snippet. The code snippet can perform one or more operations on the mobile device, including determining authentication information and communicating the authentication information to a call center system (e.g., an authentication server) to authenticate the authentication information. In some cases, the mobile device can also communicate a call session identifier with the authentication information to the call center system so that it can associate the authentication information with a pending authentication operation or request.

[0061] In box 308, routine 300 includes receiving authentication information and a call session identifier from a mobile device. In some cases, the authentication information and the call session identifier are received by an authentication server. In box 310, routine 300 determines that the authentication information is authentic. For example, the authentication server can compare the authentication information with stored authentic information. As previously described, the call session identifier can be associated with the caller (pUID) and with a specific authentication operation during the registration process. The authentication server can use the call session identifier to determine the authentic information associated with the caller by performing a lookup in a data store.

[0062] In an embodiment, the comparison result can be returned to the call center server or another device, and based on the result, the call connection can be maintained or closed. In this example, the authentication information is successfully authenticated. In box 312, routine 300 includes enabling the call connection to continue communication.

[0063] Figure 4 An example of a routine 400 that may be performed according to embodiments discussed herein is shown. In some examples, the routine 400 may be performed by a computing device, such as a mobile phone or mobile device. Embodiments are not limited to these examples.

[0064] In block 402, routine 400 includes establishing a call connection with a call center system. The call center system may be called based on the caller establishing the call connection using a mobile device. In other cases, the call connection may be established by calling the call center system of the mobile device, for example, to return a support call.

[0065] In box 404, routine 400 includes receiving a text message including a call session identifier and a mini-app link. In an embodiment, the text message can be generated and sent by a call center system. As discussed, the mini-app link can be a URL or another type of selectable link to an address for downloading a mini-app (such as a code snippet). In some cases, the caller can select the mini-app link, and the mobile device can download or retrieve the code snippet from the location specified by the link. In some cases, the code snippet may be automatically downloaded after receiving the text message. In box 406, routine 400 receives the code snippet from the server via the mobile device.

[0066] In box 408, routine 400 includes executing the code snippet. In some embodiments, the code snippet can be an executable portion of the code. The code snippet can be configured to perform an authentication operation on the mobile device. In the embodiments discussed herein, the authentication can be performed using a contactless card. For example, the code snippet can be executed to cause a display to be presented on a display of the mobile device. The display can instruct the caller to tap the contactless card on the surface of the mobile device, or to bring the card close to the mobile device. Bringing the card to a specified range (e.g., an NFC communication range) results in an exchange of data between the mobile device and the contactless card, as described herein. Figures 5 to 14 The contactless card may provide authentication information, such as encrypted data in a password.

[0067] In block 410, the routine 400 includes receiving authentication information from a contactless card based on tapping the contactless card on or near the mobile device. For example, the contactless card may communicate the authentication information to the mobile device in an NFC exchange. Embodiments are not limited in this manner and may be implemented in accordance with other short-range communication protocols such as WiFi, RF, etc.) to convey authentication information.

[0068] In box 412, routine 400 includes sending the authentication information and the call session identifier to the call center system. For example, the mobile device can send the authentication information and the call session identifier to the authentication server of the call center system to perform an authentication operation on the information, for example, to determine whether there is a match between the authentication information and the authenticated information stored on the authentication system. The authentication system can perform the authentication operation and determine a result that can be provided to the call center server and / or the mobile device. Based on the result, the call center system and / or the mobile device can determine whether to continue the call connection or stop the connection, i.e., hang up. In this routine, the call connection is maintained between the call center system and the mobile device. In box 414, routine 400 includes maintaining the call connection with the call center system based on the indication that the authentication information is authenticated.

[0069] Figure 5 An example of a process flow 500 in which a call center system may perform authentication operations to determine whether to continue a call is shown. These operations may be performed by one or more servers of the call center system, and embodiments are not limited in this manner. At box 502, the process flow 500 includes establishing a call with a telephone device (such as a mobile device or another phone). The call connection may be made via a VoIP connection, a POT connection, or other types of connections. In addition, the connection may be initiated by the call center system or other devices.

[0070] The call center system may determine to perform authentication to authenticate the caller / user of another device. In an embodiment, authentication may be performed by having the caller provide additional information (i.e., authentication information). In one example, the call center system may request the caller to authenticate the caller / user by utilizing a mini application (such as an App or Instant ) provides authentication information generated by a contactless card. The mini-application may be downloaded on a phone device that makes a call connection with another device associated with the caller (eg, a different mobile device).

[0071] At block 504, process flow 500 includes sending a text message to another device to perform authentication of the caller. In an embodiment, the text message may be sent by a call center system and include a mini-app link, such as a URL, that may be used to download the mini-app to the device. Thus, when the user selects the link, the mini-app may be downloaded from the server hosting the app. It should be noted that in some cases, the mini-app may already be installed and / or downloaded on the device, and selection of the link may result in the mini-app being executed without downloading. The link may be an address of a server of the call center system or an address of an application store hosting the mini-app.

[0072] At box 506, the process flow 500 includes receiving authentication information. In one example, the mobile device can send the authentication information, and the call center system including the authentication server can receive the authentication information. The authentication information can be collected by the mobile device. For example, the authentication information can be generated by a contactless card, and the mobile device can read the information from the card. Embodiments support other authentication information collected. For example, the additional authentication information can include a password or pin entered by the user, a biometric collected by the mobile device, or another piece of information known to the caller and the authentication system. Embodiments are not limited in this manner.

[0073] At block 508, process flow 500 includes performing an authentication operation on the authentication information. Specifically, the authentication server can compare the authentication information to understand valid and authentic information maintained by the call center system. In some embodiments, the authentication server can determine valid and authentic data in the call center system by performing a lookup in a data store using an identifier (e.g., a call session identifier).

[0074] At decision block 510, process flow 500 includes determining whether the authentication information is valid based on the result of the comparison. If the information is not authenticated, process flow 500 may continue to block 514 and the call connection may be disconnected. If the information is authenticated, process flow 500 may continue to block 512 and the connection may be maintained. In some embodiments, the caller may also perform authentication, for example, by providing a message that may be read back to the caller, as previously described.

[0075] Figure 6 A data transmission system 600 is shown according to an example embodiment. The system 600 may be an example configuration for performing authentication operations with a contactless card, including generating authentication information and communicating the authentication information to the authentication server 110. As discussed further below, the system 600 may include the contactless card 116, the mobile device 102, the network 602, and the authentication server 110. Although Figure 6 A single instance of a component is shown, but system 600 may include any number of components.

[0076] The system 600 may include one or more contactless cards 116, as will be explained further below. In some embodiments, the contactless card 116 may communicate wirelessly with the mobile device 102, in one example utilizing near field communication (NFC).

[0077] System 600 may include mobile device 102 or client device. In some embodiments, the client device may be a network-enabled computer. As described herein, a network-enabled computer may include, but is not limited to, a computer device or a communication device, including, for example, a server, a network appliance, a personal computer, a workstation, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. Mobile device 102 may be any type of mobile device; for example, the mobile device may include a computer from iPhone, iPod, iPad or other device running Apple Any other mobile device running Microsoft's Mobile operating system devices, running Google's operating system, and / or any other smartphone, tablet or similar wearable mobile device.

[0078] The mobile device 102 device may include a processor and a memory, and it should be understood that the processing circuit may contain additional components required to perform the functions described herein, including a processor, a memory, an error and parity check / CRC checker, a data encoder, an anti-collision algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware. The mobile device 102 may also include a display and an input device. The display may be any type of device for presenting visual information, such as a computer display, a flat panel display, and a mobile device screen, including a liquid crystal display, a light emitting diode display, a plasma panel, and a cathode ray tube display. The input device may include any device for inputting information into a user device, available to the user device and supported by the user device, such as a touch screen, a keyboard, a mouse, a cursor control device, a touch screen, a microphone, a digital camera, a video recorder, or a video camera. These devices may be used to input information and interact with the software and other devices described herein.

[0079] In some examples, mobile device 102 of system 600 may execute one or more applications, such as software applications, that are capable of, for example, engaging in network communications with one or more components of system 600 and transmitting and / or receiving data.

[0080] For example, the mobile device 102 can communicate with one or more servers 110 via one or more networks 602 and can operate as a respective front-end to back-end pair with the authentication server 110. The mobile device 102 can transmit one or more requests to the authentication server 110, for example, from a mobile device mini-application executing on the mobile device 102. The one or more requests can be associated with retrieving or sending data from the authentication server 110. The authentication server 110 can receive the one or more requests from the mobile device 102. Based on the one or more requests from the mobile device 102, the authentication server 110 can be configured to perform one or more operations to authenticate the authentication information.

[0081] The system 600 may include one or more networks 602. In some examples, the network 602 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect the mobile device 102 to the authentication server 110. For example, the network 602 may include one or more of: a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiple access-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 1202.11 series networking, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and / or similar networks.

[0082] In addition, the network 602 may include, but is not limited to, telephone lines, optical fibers, IEEE Ethernet 802.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. In addition, the network 602 may support the Internet, wireless communication networks, cellular networks, etc., or any combination thereof. The network 602 may also include a network, or any number of networks of the above exemplary types, operating as independent networks or in cooperation with each other. The network 602 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 602 may convert other protocols to one or more protocols of network devices. Although the network 602 is depicted as a single network, it should be understood that according to one or more examples, the network 602 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

[0083] The system 600 may include one or more authentication servers 110. In some examples, the authentication server 110 may include one or more processors coupled to a memory. The authentication server 110 may be configured as a central system, server, or platform that controls and calls various data at different times to perform multiple workflow actions. The authentication server 110 may be configured to connect to other devices and systems, including one or more databases configured to store authenticated information. The authentication server 110 may be connected to at least one mobile device 102.

[0084] Figure 7 An example configuration of a contactless card 116 is shown, which may include a payment card such as a credit card, debit card, or gift card issued by a service provider (as shown by a service provider mark 702 on the front or back of the contactless card 116). In some examples, the contactless card 116 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, a transaction card may include a dual-interface contactless payment card, and a reward card, etc. The contactless card 116 may include a substrate 708, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Typical 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 116 may have physical characteristics of an ID-1 format that conforms to the ISO / IEC 7816 standard, and the transaction card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that a contactless card 116 according to the present disclosure may have different characteristics and the present disclosure does not require a transaction card to be implemented in a payment card.

[0085] The contactless card 116 may also include identification information 706 displayed on the front and / or back of the card and a contact pad 704. The contact pad 704 may include one or more pads and is configured to establish communication with another client device (such as an ATM, user device, smartphone, laptop, desktop, or tablet) via a transaction card. The contact pad may be designed according to one or more standards (such as the ISO / IEC 7816 standard) and may be capable of communicating according to the EMV protocol. The contactless card 116 may also include processing circuitry, an antenna, and other components, as will be described in detail in the accompanying drawings. Figure 8 These components may be located behind the contact pads 704 or elsewhere on the substrate 708, such as in a different layer of the substrate 708, and may be electrically and physically coupled to the contact pads 704. The contactless card 116 may also include a magnetic stripe or tape, which may be located on the back of the card ( Figure 7 ). The contactless card 116 may also include a near field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. The embodiments are not limited in this manner.

[0086] like Figure 7 As shown, the contact pad 704 of the contactless card 116 may include processing circuitry 816 for storing, processing, and communicating information, including a processor 802, a memory 804, and one or more interfaces 806. It should be understood that the processing circuitry 816 may include additional components as necessary to perform the functions described herein, including processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware.

[0087] The memory 804 can be a read-only memory, a write-once-read-many memory or a read / write memory, for example, a RAM, a ROM and an EEPROM, and the contactless card 116 can include one or more of such memories. The read-only memory can be programmed to be read-only or one-time programmable at the factory. One-time programmability provides an opportunity to write once and then read multiple times. The write-once / read-many memory can be programmed at a certain point in time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. The read / write memory can be programmed and reprogrammed many times after leaving the factory. The read / write memory can also be read multiple times after leaving the factory. In some cases, the memory 804 can be an encrypted memory encrypted by an encryption algorithm executed by the processor 802 to the encrypted data.

[0088] The memory 804 may be configured to store one or more applets 808, one or more counters 810, a customer identifier 814, and one or more account numbers 812, which may be virtual account numbers. The one or more applets 808 may include a card configured to receive a payment on one or more contactless cards (such as The one or more software applications executed on a Java Card applet). However, it should be understood that the one or more applets 808 are not limited to Java Card applet, but can be any software application that can operate on a contactless card or other device with limited memory. One or more counters 810 may include a digital counter sufficient to store an integer. The customer identifier 814 may include a unique alphanumeric identifier assigned to the user of the contactless card 116, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 814 may identify both the customer and the account assigned to the customer, and may also identify the contactless card 116 associated with the customer account. As described above, the one or more account numbers 812 may include thousands of single-use virtual account numbers associated with the contactless card 116. The one or more applets 808 of the contactless card 116 can be configured to manage the one or more account numbers 812 (e.g., select the one or more account numbers 812, mark the selected one or more account numbers 812 as used, and transmit the one or more account numbers 812 to the mobile device for autofill through the autofill service. In some embodiments, the one or more applets 808 are configured to generate authentication information, as will be discussed in more detail herein.

[0089] The processor 802 and memory elements of the above exemplary embodiments are described with reference to the contact pad 704, but the present disclosure is not limited thereto. It should be understood that these elements may be implemented outside the contact pad 704, or completely separate therefrom, or as further elements outside the processor 802 and memory 804 elements located within the contact pad 704.

[0090] In some examples, the contactless card 116 can include one or more antennas 818. The one or more antennas 818 can be placed inside the contactless card 116 and around the processing circuit 816 of the contact pad 704. For example, the one or more antennas 818 can be integrated with the processing circuit 816, and the one or more antennas 818 can be used with an external booster coil. As another example, the one or more antennas 818 can be external to the contact pad 704 and the processing circuit 816.

[0091] In one embodiment, the coil of the contactless card 116 can be used as the secondary of an air-core transformer. The terminal can communicate with the contactless card 116 by cutting off power or amplitude modulation. The contactless card 116 can infer data transmitted from the terminal by using the gap in the contactless card power connection, which can be functionally maintained by one or more capacitors. The contactless card 116 can perform reverse communication by switching a load or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference. More generally, using one or more antennas 818, processors 802 and / or memory 804, the contactless card 101 provides a communication interface to communicate via NFC, Bluetooth and / or Wi-Fi communications.

[0092] As described above, the contactless card 116 can be built on a software platform operable on a smart card or other device with limited memory (such as a JavaCard), and can securely execute one or more applications or applets. One or more applets 808 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 808 can be configured to respond to one or more requests (such as a near-field data exchange request) from a reader (such as a mobile NFC reader (e.g., a mobile device or a point-of-sale terminal)) and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag.

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

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

[0095] In some examples, the contactless card 116 and the server may include certain data so that the card can be properly identified, such as authentication information. The contactless card 116 may include one or more unique identifiers (not shown). Each time a read operation occurs, the one or more counters 810 may be configured to increment. In some examples, each time data from the contactless card 116 is read (e.g., by a mobile device), the one or more counters 810 are transmitted to the server for verification, and a determination is made as to whether the one or more counters 810 are equal (as part of the verification) to the server's counters.

[0096] The one or more counters 810 may be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password will be immediately rejected if the one or more counters 810 have been read or used or otherwise passed. If the one or more counters 810 have not been used, they may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. Since there is no communication between the one or more applets 808 on the contactless card 116, the contactless card 101 cannot determine the one or more application transaction counters 810.

[0097] In some examples, one or more counters 810 may not be synchronized. In some examples, to account for unexpected reads that initiate a transaction (such as reading at an angle), one or more counters 810 may be incremented, but the application does not process one or more counters 810. In some examples, when the mobile device 10 is awake, NFC may be enabled, and the mobile device 102 may be configured to read available tags, but not take any action on the reads.

[0098] In order to keep one or more counters 810 synchronized, an application (such as a background application) can be executed, which will be configured to detect when the mobile device 110 wakes up and synchronizes with the server of the banking system, indicating the reading that occurred due to the detection, and then moving the counter forward. In other examples, a hashed one-time password can be used to allow a window of acceptable missynchronization. For example, if it is within a threshold of 10, one or more counters 810 can be configured to move forward. But if it is within a different threshold number, such as within 10 or 1000, a request to perform resynchronization can be processed, which requests the user to tap, gesture or otherwise indicate once or multiple times via the user's device via one or more applications. If one or more counters 810 increase in an appropriate sequence, it can be known that the user has done so.

[0099] The key diversification technique described herein with reference to one or more counters 810, master keys, and diversification keys is an example of an encryption and / or decryption key diversification technique. This example key diversification technique should not be considered a limitation of the present disclosure, as the present disclosure is equally applicable to other types of key diversification techniques.

[0100] During the creation process of the contactless card 116, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which may be used for encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and implemented by hardware in the contactless card 116. Using a key diversification process, one or more keys may be derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0101] In some examples, to overcome the shortcomings of the 3DES algorithm that may be susceptible to vulnerabilities, a session key (such as a unique key for each session) can be derived, instead of using a master key, a unique card derived key and a counter can be used as diversification data. For example, each time the contactless card 101 is used in operation, a different key can be used to create a message authentication code (MAC) and perform encryption. This results in a three-layer password. The session key can be generated by one or more applets and derived by using an application transaction counter with one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0102] Additionally, the increments may be unique for each card and may be assigned by personalization, or algorithmically assigned by some identifying information. For example, odd-numbered cards may be incremented by 2, and even-numbered cards may be incremented by 5. In some examples, the increments may also vary across sequential reads, such that a card may be incremented in the order 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined at personalization time, or from one or more processes derived from the unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

[0103] The authentication information included in the authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0104] Fig. 9is a timing diagram illustrating an example sequence for providing authentication information according to one or more embodiments of the present disclosure. Sequence flow 900 may include contactless card 116 and mobile device 102, which may include application 902 (such as a mini-application or code snippet described herein) and processor 904.

[0105] At line 908, the application 902 communicates with the contactless card 116 (e.g., after being brought into proximity with the contactless card 116). The communication between the application 902 and the contactless card 116 may involve the contactless card 116 being brought sufficiently close to a card reader (not shown) of the mobile device 102 to enable NFC data transfer between the application 902 and the contactless card 116.

[0106] At line 906, after communication is established between the mobile device 102 and the contactless card 116, the contactless card 116 generates a message authentication code (MAC) password. In some examples, this may occur when the contactless card 116 is read by the application 902. In particular, this may occur when reading (such as, NFC reading) a near field data exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a card reader application (such as application 902) may transmit a message (such as an applet selection message) with an applet ID of an NDEF production applet. After confirming the selection, a series of select file messages may be transmitted, followed by a read file message. For example, the sequence may include "select capability file", "read capability file" and "select NDEF file". At this time, a counter value maintained by the contactless card 116 may be updated or incremented, followed by "read NDEF file". At this time, a message may be generated that may include a header and a shared secret. A session key may then be generated. A MAC password may be created from the message, which may include a header and a shared secret. The MAC password can then be concatenated with one or more random data blocks, and the MAC password and random number (RND) can be encrypted with the session key. Thereafter, the password and header can be concatenated and encoded as ASCII hexadecimal and returned in the NDEF message format (in response to the "Read NDEF File" message).

[0107] In some examples, the MAC password can be sent as an NDEF tag, and in other examples, the MAC password can be included in a uniform resource indicator (e.g., as a formatted string). In some examples, the application 902 can be configured to transmit a request to the contactless card 116, the request including instructions to generate the MAC password.

[0108] At line 910, the contactless card 116 sends the MAC password to the application 902. In some examples, the transmission of the MAC password occurs via NFC, however, the present disclosure is not limited thereto. In other examples, such communication may occur via Bluetooth, Wi-Fi, or other wireless data communication methods. At line 912, the application 902 communicates the MAC password to the processor 904.

[0109] At line 914, processor 904 verifies the MAC password according to the instruction from application 122. For example, the MAC password can be verified as explained below. In some examples, verifying the MAC password can be performed by a device other than mobile device 102, such as a server of a banking system that performs data communication with mobile device 102. For example, processor 904 can output the MAC password for transmission to the server of the banking system, which can verify the MAC password. In some examples, the MAC password can be used as a digital signature for verification. Other digital signature algorithms (such as public key asymmetric algorithms, such as digital signature algorithms and RSA algorithms, or zero-knowledge protocols) can be used to perform this verification.

[0110] Fig.10 An NDEF short record layout (SR=1) data structure 1000 is shown according to an example embodiment. One or more applets may be configured to encode the OTP as a well-known type text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet may 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: well-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 personalized parameters that can be used to generate NDEF messages. In one embodiment, the authentication template may include a first record having a well-known index for providing actual dynamic authentication information.

[0111] Fig.11 A schematic diagram of a system 1100 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 can include symmetric keys that can be used for encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV and implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from a master key based on uniquely identifiable information for each entity that needs a key.

[0112] With respect to master key management, two issuer master keys 1102, 1126 may be required for each portion of a portfolio that issues one or more applets. For example, the first master key 1102 may include an issuer password generation / authentication key (Iss-key-Auth), and the second master key 1126 may include an issuer data encryption key (Iss-key-DEK). As further explained herein, the two issuer master keys 1102, 1126 are diversified into card master keys 1108, 1120, which are unique to each card. In some examples, a network profile record ID (pNPR) 522 and a derived key index (pDKI) 1124 as background data may be used to identify which issuer master key 1102, 1126 to use for authentication during the password process. The system performing the authentication may be configured to retrieve the values ​​of the pNPR 1122 and pDKI 1124 of the contactless card at the time of authentication.

[0113] In some examples, to improve the security of the solution, session keys (such as unique keys for each session) can be derived, but as explained above, unique card-derived keys and counters can be used as diversified data instead of using a master key. For example, each time a card is used in an operation, a different key can be used to create a message authentication code (MAC) and perform encryption. Regarding session key generation, the keys used to generate passwords and encrypt data in one or more applets can include session keys based on card unique keys (Card-Key-Auth 1108 and Card-Key-Dek 1120). Session keys (Aut-Session-Key 1132 and DEK-Session-Key 1110) can be generated by one or more applets and derived by using an application transaction counter (pATC) 1104 with one or more algorithms. In order to fit the data into one or more algorithms, only the 2 low-order bytes of the 4-byte pATC 1104 are used. In some examples, a 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 3DES ECB, and MK may include a card-uniquely derived master key.

[0114] As described herein, the lower two bytes of the pATC 1104 counter may be used to derive one or more MAC session keys. At each tap of a contactless card, the pATC 1104 is configured to be updated, and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 1120 are further diversified into session keys Aut-Session-Key 1132 and DEK-Session-KEY 1110. The pATC 1104 may be initialized to zero at personalization or applet initialization. In some examples, the pATC counter 1104 may be initialized at or before personalization and may be configured to increment by one at each NDEF read.

[0115] Additionally, updates for each card may be unique and may be assigned either by personalization or by algorithmic assignment of a pUID or other identifying information. For example, odd-numbered cards may be incremented or decremented by 2, and even-numbered cards may be incremented or decremented by 5. In some examples, updates may also vary in sequential reads, such that a card may be incremented repeatedly in the sequence 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence may be defined at personalization time, or from one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

[0116] 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, only the authentication data and the 8-byte random number of the MAC following the authentication data can be included. In some examples, the random number can be before the password A and can be a block length. In other examples, there may be no limit on the length of the random number. In a further example, the total data (i.e., the random number plus the password) can be a multiple of the block size. In these examples, additional 8-byte blocks can be added to match the blocks generated by the MAC algorithm. As another example, if the algorithm used uses 16-byte blocks, multiples of the block size can be used, or the output can be automatically or manually padded to a multiple of the block size.

[0117] The MAC may be performed by a function key (AUT-Session-Key) 1132. The data specified in the cipher may be processed with the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 associated with the EMV ARQC authentication method. As explained above, the keys used for this calculation may include a session key AUT-Session-Key 1132. As explained above, the lower two bytes of the counter may be used to diversify one or more MAC session keys. As explained below, the AUT-Session-Key 1132 may be used to MAC data 1106, and the resulting data or cipher An 1114 and random number RND may be encrypted using the DEK-Session-Key 1110 to create the cipher B or output 1118 sent in the message.

[0118] In some examples, one or more HSM commands may be processed for decryption such that the final 16 (binary, 32 hex) bytes may include a 3DES symmetric encryption using CBC mode with a random IV of zero followed by MAC authentication data. The key used for this encryption may include a session key DEK-Session-Key 1110 derived from Card-Key-DEK 1120. In this case, the ATC value derived from the session key is the least significant byte of the counter pATC 1104.

[0119] The following format represents a binary version example embodiment. Additionally, in some examples, the first byte may be set to ASCII "A".

[0120]

[0121]

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

[0123]

[0124]

[0125] The UID field of the received message may be extracted to derive the card master keys (Card-Key-AUTH 1108 and Card-Key-DEK 1120) for that particular card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 1126. Using the card master keys (Card-Key-Auth 508 and Card-Key-DEK 1120), the counter (pATC) field of the received message may be used to derive the session keys (AUT-Session-Key 1132 and DEK-Session-Key 1110) for that particular card. The cryptogram B 1118 may be decrypted using the DEK-Session-KEY, which produces the cryptogram An 1114 and RND, and the RND may be discarded. The UID field can be used to look up the contactless card's shared secret key, which, along with the Ver, UID, and pATC fields of the message, can be processed through an encrypted MAC using the recreated Aut-Session-Key to create a MAC output, such as MAC'. If MAC' is the same as the secret code An 1114, this indicates that both the message decryption and the MAC check have passed. The pATC can then be read to determine if it is valid.

[0126] During the authentication session, one or more passwords may be generated by one or more applications. For example, the one or more passwords may be generated as a 3DES MAC via one or more session keys (such as AUT-Session-Key 1132) using ISO 9797-1 Algorithm 3 with Method 2 padding. The input data 1106 may take the following form: version (2), pUID (8), pATC (4), shared key (4). In some examples, the number in brackets may include a length in bytes. In some examples, the shared key may be generated by one or more random number generators that may be configured to ensure that the random number is unpredictable through one or more security processes. In some examples, the shared key may include a random 4-byte binary number known to the authentication service that is injected into the card at personalization time. During the authentication session, the shared key may not be provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte at the end of the input data, and a 0x'00' byte that may be added to the end of the resulting data until an 8-byte boundary. The length of the resulting password may include 8 bytes.

[0127] In some examples, one benefit of using a MAC cipher to encrypt the unshared random number as the first block is that it acts as an initialization vector when using the CBC (block chaining) mode of a symmetric encryption algorithm. This allows "scrambling" from block to block without the need to pre-establish a fixed or dynamic IV.

[0128] By including an application transaction counter (pATC) as part of the data included in the MAC cipher, the authentication service can be configured to determine whether the value transmitted in the plaintext data has been tampered with. In addition, by including the version in one or more ciphers, it is difficult for an attacker to intentionally misrepresent the application version in an attempt to reduce the strength of the cipher solution. In some examples, the pATC can start at zero and be updated by 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 that is equal to or lower than a previous value 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 whether it is within an acceptable range or threshold, and if it exceeds or exceeds the range or threshold, the authentication can be considered failed or unreliable. In MAC operation 1112, the data 1106 is processed by MAC using the AUT-Session-Key 1132 to produce a MAC output (cipher A) 1114, which is encrypted.

[0129] To provide additional protection against brute force attacks that expose the keys on the card, it is preferred that the MAC password 1114 be encrypted. In some examples, the data or password An 1114 to be included in the ciphertext may include: random number (8), password (8). In some examples, the number in brackets may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that may be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include a DEK-Session-Key 1110. In an encryption operation 1116, the data or password An 1114 and RND are processed using the DEK session key 510 to produce encrypted data, password B 1118. The data may be encrypted using 3DES in a cipher block chaining mode to ensure that an attacker must perform any attack on all ciphertexts. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' may 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, as correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.

[0130] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plain text from the one or more applets to the mobile device during the authentication session: determining the version number of the encryption method used and the message format used for verification of the password, which allows the method to be changed in the future; retrieving the pUID of the cryptographic asset and deriving the card key; and deriving the pATC of the session key for the password.

[0131] Fig.12 A method 1200 for generating a cryptogram is shown. For example, at block 1202, a network profile record ID (pNPR) and a derived key index (pDKI) may be used to identify which issuer master key to use in a cryptogram process for authentication. In some examples, the method may include performing authentication to retrieve the values ​​of the pNPR and pDKI of a contactless card at the time of authentication.

[0132] At block 1204, the issuer master key may be diversified by combining it with the card's unique ID number (pUID) and a PAN serial number (PSN) of one or more applets (eg, a payment applet).

[0133] At block 1206, a session key may be generated by diversifying the issuer master key, thereby creating Card-Key-Auth and Card-Key-DEK (card-unique key), which may be used to generate a MAC password.

[0134] At block 1208, the keys used to generate the password and encrypt the data in the one or more applets may include the session keys of block 1030 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 the session keys Aut-Session-Key and DEK-Session-Key.

[0135] Fig.13 An exemplary process 1300 showing key diversification according to one example is depicted. Initially, two different master keys may be provided to a sender and a receiver. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value, which may be updated at block 1302, and other data (such as data to be protected), which may be securely shared with the receiver.

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

[0137] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and the receiver in plain text (ie, without encryption).

[0138] The data to be protected is cryptographically MACed by the sender using the data integrity session key and a cryptographic MAC algorithm at block 1306. The protected data (including plaintext and shared key) may be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0139] At block 1308, the data to be protected may be encrypted by the sender using a session key derived from data encryption in conjunction 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).

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

[0141] At block 1312, the recipient independently derives two derived session keys from the two master keys using the received counter value, as explained above.

[0142] At block 1314, the session key derived from the data encryption is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing is then performed on the exchanged data. In some examples, after the MAC is extracted, it is desirable to reproduce and match the MAC. For example, when verifying a password, it can be decrypted using a properly generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

[0143] At block 1316, the data integrity derived session key is used in conjunction with a cryptographic MAC operation to verify that the protected data has not been modified.

[0144] Some examples of the methods described herein can advantageously confirm when authentication is determined to be successful when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is correct. The MAC may be correct only if the decryption is successful and produces the correct MAC value. Successful decryption can indicate that the correctly derived encryption key is used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., a transmitting device) and the receiver (e.g., a receiving device), it can be believed that the contactless card that originally created the MAC and the encrypted MAC are indeed authentic. In addition, the counter value used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

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

[0146] Fig.14 A method 800 for card activation according to an example embodiment is shown. For example, card activation can be accomplished by a system including a card, a device, and one or more servers. The contactless card, the device, and the one or more servers can refer to the same or similar components explained previously, such as the contactless card 116, the mobile device 102, and the server.

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

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

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

[0150] In block 1408, one or more servers may decrypt one or more encrypted portions of the 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 recorded data accessible to the one or more servers. If the comparison of the results of the one or more decrypted portions of the data by the one or more servers results in a successful match, the card may be activated. If the comparison of the results of the one or more decrypted portions of the data by the one or more servers results in an unsuccessful match, one or more processes may be performed. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold, including a number of attempts 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 attempt to verify the card was unsuccessful, and call, email, or text an associated service to assist in activating the card; or receive another notification, such as a phone call indicating that the attempt to verify the card was unsuccessful on his or her device, and call, email, or text an associated service to assist in activating the card; or receive another notification, such as an email indicating that the attempt to verify the card was unsuccessful, and call, email, or text an associated service to assist in activating the card.

[0151] In block 1410, one or more servers may transmit a return message based on the successful activation of the card. For example, the device may be configured to receive an output from the one or more servers indicating that the one or more servers successfully activated the card. The device may be configured to display a message indicating the successful activation of the card. Once the card is activated, the card may be configured to stop dynamically generating data to avoid fraudulent use. In this way, the card may not be activated thereafter, and the one or more servers receive notification that the card has been activated.

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

[0153] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities: hardware, a combination 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 drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, both an application running on a server and a server can be a component. One or more components can reside in a process and / or an execution thread, and a component can be localized on one computer and / or distributed between two or more computers. In addition, components can be communicatively coupled to each other through various types of communication media to coordinate operations. Coordination may involve unidirectional or bidirectional information exchange. For example, a component can transmit information in the form of a signal transmitted through a communication medium. The information can be implemented as a signal assigned to various signal lines. In this assignment, each message is a signal. However, other embodiments may alternatively adopt data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

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

[0155] like Fig.15 As shown, computing architecture 100 includes processor 1512, system memory 1504, and system bus 1506. Processor 1512 may be any of a variety of commercially available processors.

[0156] The system bus 1506 provides an interface for system components, including but not limited to the system memory 1504 to the processor 1512. The system bus 1506 can be any of several types of bus structures, which can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus 608 via a slot architecture. 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)), PCI Express, personal computer memory card international association (PCMCIA), and similar architectures.

[0157] The computing architecture 100 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 media capable of storing electronic data, including volatile memory or non-volatile storage, removable memory or non-removable memory, erasable memory or non-erasable memory, and writable memory 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 the like. Embodiments may also be implemented at least in part as instructions contained in or on a non-transient computer-readable medium, which may be read and executed by one or more processors to implement the operations described herein.

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

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

[0160] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in the drives and nonvolatile 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, for example, various applications and / or components of the systems discussed herein.

[0161] A user may enter commands and information into the computer 1502 through one or more wired / wireless input devices (e.g., a keyboard 1550 and a pointing device such as a 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, graphic tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and similar input devices. These and other input devices are typically connected to the processor 1512 through an input device interface 1536 coupled to the system bus 1506, but may be connected through other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR port, and the like.

[0162] A display 1544 or other type of display device is also connected to the system bus 1506 via an interface, such as a video adapter 1546. The display 1544 may be internal or external to the computer 1502. In addition to the display 1544, computers typically include other peripheral output devices, such as speakers, and printers.

[0163] The computer 1502 can operate in a network 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 devices, or other public network nodes, and typically include many or all of the elements described relative to the computer 1502, although only a memory and / or storage device 1558 is shown for simplicity. The depicted logical connections include wired / wireless connections to a local area network 1556 and / or a larger network, such as a wide area network 1554. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communication network, such as the Internet.

[0164] When used in a LAN 1556 networking environment, the computer 1502 is connected to the LAN 1556 through a wired and / or wireless communication network interface or network adapter 1538. The network adapter 1538 can facilitate wired and / or wireless communications with the LAN 1556, which can also include a wireless access point disposed thereon for communicating with the wireless functionality of the network adapter 1538.

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

[0166] The computer 1502 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communications (e.g., IEEE 802.11 over-the-air modulation techniques). This includes at least Wi-Fi (or wireless LAN), WiMax, and Bluetooth. TMWireless technology and other technologies. Therefore, the communication can be a predefined structure like a conventional network, or just an ad hoc communication between at least two devices. Wi-Fi networks use radio technology called IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use media and functions related to IEEE 802.3).

[0167] As previously described herein, various elements of the device may include various hardware elements, software elements, or a combination of the two. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, and inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, and chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, application interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether to use hardware elements and / or software elements to implement an embodiment can vary depending on many factors, such as desired computing rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints as desired for a given implementation.

[0168] The components and features of the above-described devices may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or monolithic architectures. In addition, where appropriate, features of the devices may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the above. It should be noted that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0169] Fig.16 1 is a block diagram depicting an exemplary communication architecture 1600 suitable for implementing various embodiments as previously described. The communication architecture 1600 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, and power supplies, etc. However, the embodiments are not limited to implementation by the communication architecture 1600, which can be consistent with the systems and devices discussed herein.

[0170] like Fig.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 can implement one or more functions and embodiments discussed herein. The one or more clients 1602 and the one or more servers 1604 are operably connected to one or more corresponding client data stores 1606 and server data stores 1608, which can be used to store information local to the one or more corresponding clients 1602 and the one or more servers 1604, such as Cookies and / or associated context information.

[0171] One or more clients 1602 and one or more servers 1604 can communicate information between each other using a communication framework 1610. The communication framework 1610 can implement any well-known communication technologies and protocols. The communication framework 1610 can be implemented as a packet switching network (e.g., a public network such as the Internet, a private network such as a corporate intranet), a circuit switching network (e.g., a public switched telephone network), or a combination of packet switching networks and circuit switching networks (with appropriate gateways and switches).

[0172] The communication framework 1610 can implement various network interfaces arranged to accept, communicate and connect to the communication network. The network interface can be regarded as a special form of input / output (I / O) interface. The network interface can adopt connection protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000BaseT, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7ax network interface, IEEE 802.16 network interface, IEEE 802.20 network interface and similar network interfaces. In addition, multiple network interfaces can be used to engage with various communication network types. For example, multiple network interfaces can be used to allow communication through broadcast, multicast and unicast networks. If the processing requirements specify a greater speed and capacity, a distributed network controller architecture can be similarly used to pool, load balance and otherwise increase the communication bandwidth required for 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 interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operating missions as nodes in the Internet (OMNI), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

Claims

1. A computer-implemented method comprising: The call center system establishes a call connection with the mobile device; determining, by the call center system, a call session identifier for the call connection and a telephone number associated with the mobile device; sending, by the call center system, a text message to the mobile device based on the phone number, the text message including the call session identifier and a mini-application link, the mini-application link being configured to retrieve a code snippet from a server by the mobile device; receiving, by the call center system, authentication information and the call session identifier from the mobile device, the authentication information being generated by a contactless card; The call center system determines that the authentication information is authentic; as well as The call connection is enabled by the call center system to continue communications.

2. The computer-implemented method of claim 1 , wherein: The code snippet is retrieved from the server based on a user interaction with the mini-app link, and the mini-app link is a uniform resource locator of the server that includes the code snippet.

3. The computer-implemented method of claim 1 , wherein: The server is maintained by an application store, and the code snippet is downloadable to the mobile device in response to a selection.

4. The computer-implemented method of claim 1 , wherein: The code snippet is configured to execute on the mobile device and present an indication on a display of the device to tap the contactless card on a surface of the mobile device.

5. The computer-implemented method of claim 1 , comprising: registering, by the call center system, a request to perform authentication of the call connection; as well as The call session identifier is generated by the call center system based on registering the request.

6. The computer-implemented method of claim 1 , comprising: Determining, by the call center system, a telephone number for the call connection; determining, by the call center system, that an account is associated with a telephone number of the mobile device; as well as The text message is automatically sent by the call center system to the mobile device based on a determination that the account is associated with the phone number.

7. The computer-implemented method of claim 1, comprising receiving, by the call center system from the mobile device, a second text message including a code for performing authentication of a call agent of the call center system.

8. The computer-implemented method of claim 1, wherein: The call center system receives the authentication information from a code snippet executed on the mobile device, wherein the code snippet is configured to perform a read operation through the contactless card to receive the authentication information and send it to the call center system.

9. A call center system, comprising: Processing circuit; and a memory storing instructions which, when executed by the processing circuit, cause the circuit to: confirming call connection with the mobile device; determining a telephone number associated with the mobile device; sending a text message to the mobile device based on the phone number, the text message including a mini-app link, the mini-app link configured to retrieve a code snippet on the mobile device; receiving authentication information from the mobile device, the authentication information being generated by a contactless card; authenticating the authentication information; as well as Based on the authentication information being authentic, the call center system enables the call connection to continue communication.

10. The system according to claim 9, wherein: The code snippet is received from a server based on a user interaction with the mini-app link, and the mini-app link is a uniform resource locator of the server that includes the code snippet.

11. The system according to claim 10, wherein: The server is maintained by an application store, and the code snippet is downloadable to the mobile device in response to a selection.

12. The system according to claim 9, wherein: The code snippet is configured to execute on the mobile device and present an indication on a display of the device to tap the contactless card on a surface of the mobile device.

13. The system of claim 9, comprising further instructions causing the processing circuit to: registering a request to perform authentication of the call connection; and generating a call session identifier based on registering the request, wherein: The call session identifier is communicated to the mobile device and used by the call center system to associate the authentication of the authentication information with the call connection.

14. The system of claim 9, comprising further instructions causing the processing circuit to: Determining a telephone number to which the call is connected; determining an account is associated with the phone number of the mobile device; and The text message is automatically sent to the mobile device based on associating an account with the phone number.

15. The system of claim 9, comprising further instructions that cause the processing circuit to: receive a second text message from the mobile device, the text message comprising code for performing authentication of a call agent of the call center system.

16. The system of claim 9, wherein: The call center system receives the authentication information from a code snippet executed on the mobile device, wherein the code snippet is configured to perform a read operation through the contactless card to receive the authentication information and send it to the call center system.

17. A computer-implemented method comprising: The mobile device establishes a call connection with the call center system; receiving, by the mobile device, a text message including a call session identifier and a mini-application link, the mini-application link being configured to retrieve a code snippet from a server; Receiving, by the mobile device, the code snippet from the server; executing the code segment by the mobile device, the code segment causing a prompt to tap a contactless card on or near the mobile device to be presented on a display of the mobile device; receiving, by the mobile device, authentication information from the contactless card based on tapping the contactless card on or near the mobile device; sending, by the mobile device, the authentication information and the call session identifier; as well as A call connection with the call center system is maintained by the mobile device based on an indication that the authentication information is authenticated.

18. The computer-implemented method of claim 17, comprising sending, by the mobile device, a second text message, the second text message comprising a code for performing authentication of a call agent of the call center system.

19. The computer-implemented method of claim 17, wherein: The mini-app link is a uniform resource locator of a server that includes the code snippet.

20. The computer-implemented method of claim 17, wherein: The server is maintained by an application store, and the code snippet is downloadable to the mobile device in response to a selection.

Images