Patent Description:
Identity verification is an important task for modern computing systems. Conventional approaches may require that users provide additional information, such as a one-time passcode (OTP), when attempting to access computing systems or perform electronic transactions. However, security vulnerabilities may exist in these solutions. For example, the OTP may be intercepted and used to gain unauthorized access. Furthermore, different systems may require different types of additional information for identity verification, making conventional solutions impractical for many users.

<CIT> relates to mobile computing platforms, and more specifically, to tap to copy data to a clipboard via near-field communication (NFC).

<CIT> relates to data communications and more specifically to information security.

Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for secure authentication based on identity data stored in a contactless card. In one example, an application may receive an indication specifying to perform an operation associated with an account. The application may receive encrypted data from a contactless card associated with the account, the encrypted data based on a cryptographic algorithm, a customer identifier, and a private key for the contactless card. The application may receive, from an authentication server, an indication specifying that the authentication server verified the encrypted data based on the private key for the contactless card. The application may receive encrypted passport data from the contactless card, the encrypted passport data for a passport associated with the account. The application may determine an attribute of the passport based at least in part on image data or text input. The application may decrypt the encrypted passport data based on the attribute of the passport. The application may initiate performance of the operation based on the received indication specifying that the authentication server verified the encrypted data and the decryption of the encrypted passport data.

According to a first aspect of the invention there is provided a system, comprising: a processor; and a memory storing instructions which when executed by the processor cause the processor to: receive, by an application executing on the processor, a request to perform an operation associated with an account; receive, by the application, encrypted data from a contactless card associated with the account, the encrypted data based on a cryptographic algorithm, a customer identifier, and a master key for the contactless card; transmit, by the application, the encrypted data to an authentication server; receive, by the application from the authentication server, an indication specifying that the authentication server verified the encrypted data based on the master key for the contactless card; receive, by the application, encrypted passport data from the contactless card, the encrypted passport data for a passport, the encrypted passport data encrypted based on at least one attribute of the passport; determine, by the application, the at least one attribute of the passport based at least in part on image data or text input; decrypt, by the application, the encrypted passport data based on the at least one attribute of the passport; and initiate performance of the operation based on the received indication specifying that the authentication server verified the encrypted data and the decryption of the encrypted passport data.

According to a second aspect of the invention there is provided a non-transitory computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by a processor to cause the processor to: receive, by an application executing on the processor, a request to perform an operation associated with an account; receive, by the application, encrypted data from a contactless card associated with the account, the encrypted data based on a cryptographic algorithm, a customer identifier, and a master key for the contactless card; transmit, by the application, the encrypted data to an authentication server; receive, by the application from the authentication server, an indication specifying that the authentication server verified the encrypted data based on the master key for the contactless card; receive, by the application, encrypted passport data from the contactless card, the encrypted passport data for a passport, the encrypted passport data encrypted based on at least one attribute of the passport; determine, by the application, the at least one attribute of the passport based at least in part on image data or text input; decrypt, by the application, the encrypted passport data based on the at least one attribute of the passport; and initiate performance of the operation based on the received indication specifying that the authentication server verified the encrypted data and the decryption of the encrypted passport data.

According to a third aspect of the invention there is provided a method, comprising: receiving, by an application executing on a processor, a request to perform an operation associated with an account; receiving, by the application, encrypted data from a contactless card associated with the account, the encrypted data based on a cryptographic algorithm, a customer identifier, and a master key for the contactless card; transmitting, by the application, the encrypted data to an authentication server; receiving, by the application from the authentication server, an indication specifying that the authentication server verified the encrypted data based on the master key for the contactless card; receiving, by the application, encrypted passport data from the contactless card, the encrypted passport data for a passport, the encrypted passport data encrypted based on at least one attribute of the passport; determining, by the application, the at least one attribute of the passport based at least in part on image data or text input; decrypting, by the application, the encrypted passport data based on the at least one attribute of the passport; and initiating performance of the operation based on the received indication specifying that the authentication server verified the encrypted data and the decryption of the encrypted passport data.

Embodiments disclosed herein provide techniques for secure authentication using passport data stored in a contactless card. Generally, a contactless card may store a plurality of different types of information for a user, such as payment information, passport information, and/or any other biographical information. The user may then attempt to perform an operation, such as making a purchase, transferring funds via an application executing on a mobile device, requesting a credit increase via the application, and the like. The application may determine a type of authentication data required to authorize the requested operation. For example, a rule may specify that transferring funds via the application requires authentication based on passport data stored in the contactless card. Therefore, the application may determine that passport data as the type of authentication data.

The user may then tap the contactless card to the mobile device to initiate the secure authentication process. Once tapped, the contactless card may generate and transmit encrypted data to the application. The encrypted data may be generated based on a cryptographic algorithm, a customer identifier, and an encryption key for the contactless card. The application may then transmit the encrypted data to an authentication server for authentication. The server may then decrypt the encrypted data using a local copy of the encryption key for the contactless card to yield the customer identifier, thereby authenticating the encrypted data. The server may then transmit an indication of the authentication of the encrypted data to the application.

The application may then attempt to decrypt the passport data. In some embodiments, the passport data is sent by the contactless card to the application with the encrypted customer identifier. In other embodiments, the passport data is separately sent by the contactless card subsequent to another tap of the contactless card to the mobile device. To decrypt the passport data, the application may receive one or more attributes of the passport. For example, an image depicting one or more pages of the passport may be captured, and the attributes may be extracted from the captured image. As another example, the user may provide the attributes as input. The application may then authorize the performance of the operation based on the received indication specifying that the authentication server verified the encrypted data and the decryption of the passport data. For example, the user may be permitted to access an interface of the application to transfer funds from one account to another.

Advantageously, embodiments disclosed herein improve the security of all devices and associated data. For example, by requiring validation of encrypted data generated by the contactless card to access applications and/or data, the security of the applications and/or data are improved. As another example, by requiring validation of the encrypted passport data prior to performing operations (e.g., making purchases, extending credit, etc.), the security of such operations and associated assets is improved.

With general reference to notations and nomenclature used herein, one or more portions of the detailed description which follows may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substances of their work to others skilled in the art. A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

Further, these manipulations are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein that form part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing operations of various embodiments include digital computers as selectively activated or configured by a computer program stored within that is written in accordance with the teachings herein, and/or include apparatus specially constructed for the required purpose or a digital computer. Various embodiments also relate to apparatus or systems for performing these operations. These apparatuses may be specially constructed for the required purpose. The required structure for a variety of these machines will be apparent from the description given.

Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. The intention is to cover all modification, equivalents, and alternatives within the scope of the claims.

<FIG> depicts a schematic of an exemplary system <NUM>, consistent with disclosed embodiments. As shown, the system <NUM> includes one or more contactless cards <NUM>, one or more mobile computing devices <NUM>, and an authentication server <NUM>. The contactless cards <NUM> are representative of any type of payment cards, such as a credit card, debit card, ATM card, gift card, and the like. The contactless cards <NUM> may comprise one or more communications interfaces <NUM>, such as a radio frequency identification (RFID) chip, configured to communicate with the computing devices <NUM> via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an example communications protocol, the disclosure is equally applicable to other types of wireless communications, such as the EMV standard, Bluetooth, and/or Wi-Fi. The mobile devices <NUM> are representative of any type of network-enabled computing devices, such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, and the like. The authentication server <NUM> is representative of any type of computing device, such as a server, workstation, compute cluster, cloud computing platform, virtualized computing system, and the like.

As shown, a memory <NUM> of the contactless card includes an applet <NUM>, a counter <NUM>, a master key <NUM>, a diversified key <NUM>, a unique customer identifier (ID) <NUM>, and passport data <NUM>. The applet <NUM> is executable code configured to perform the operations described herein. The counter <NUM>, master key <NUM>, diversified key <NUM>, and customer ID <NUM> are used to provide security in the system <NUM> as described in greater detail below. The passport data <NUM> is representative of an electronic passport of a user associated with the contactless card <NUM>. The passport data <NUM> may include any number and types of data. For example, the passport data <NUM> may include text data describing different attributes of the passport and/or user (e.g., name, date of birth, passport number, passport issue date, passport expiration date, issuing nation, etc.) as well as image data (e.g., one or more images of the passport itself, an image of the user included in the passport, etc.). In some embodiments, the passport data <NUM> is encrypted. For example, the passport data <NUM> may be encrypted based on one or more attributes of the passport. The one or more attributes may include a passport number, a passport issue date, and/or a passport expiration date.

As shown, a memory <NUM> of the mobile device <NUM> includes an instance of an operating system (OS) <NUM>. Example operating systems <NUM> include the Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the OS <NUM> includes an account application <NUM>. The account application <NUM> allows users to perform various account-related operations, such as viewing account balances, purchasing items, processing payments, and the like. The account application <NUM> may further control access permissions to different functions provided by the account application <NUM> and/or the other applications <NUM>. Generally, a user may authenticate using authentication credentials to access certain features of the account application <NUM>. For example, the authentication credentials may include a username (or login) and password, biometric credentials (e.g., fingerprints, Face ID, etc.), and the like.

According to various embodiments, the user may request and/or attempt to perform an operation. The operation may include any type of operation, such as using the contactless card <NUM> to make a purchase, accessing certain features of the account application <NUM>, performing various account-related operations using the account application <NUM>, and/or accessing the other applications <NUM> (or any feature thereof). The other applications <NUM> are representative of any type of computing application, such as web browsers, messaging applications, word processing applications, social media applications, and the like. For example, the user may desire to transfer funds from their account to another account using the account application <NUM>. The use of a specific operation as a reference example herein is not limiting of the disclosure, as the disclosure is equally applicable to any other type of operation.

To authorize the requested operation, (e.g., the previous example of transferring funds), the system <NUM> must authenticate and/or verify the identity of the user. To authenticate the identity of the user, embodiments disclosed herein may leverage the contactless card <NUM>. More specifically, once the user requests to perform the operation (or otherwise access a restricted resource), the account application <NUM> may output a notification instructing the user to tap the contactless card <NUM> to the device <NUM>. Generally, once the contactless card <NUM> is brought within communications range of the communications interface <NUM> of the device <NUM>, the applet <NUM> of the contactless card <NUM> may generate encrypted data, e.g., an encrypted customer ID <NUM> as part of the authentication process required to authorize the requested operation. To enable NFC data transfer between the contactless card <NUM> and the mobile device <NUM>, the account application <NUM> may communicate with the contactless card <NUM> when the contactless card <NUM> is sufficiently close to the communications interface <NUM> of the mobile device <NUM>. The communications interface <NUM> may be configured to read from and/or communicate with the communications interface <NUM> of the contactless card <NUM> (e.g., via NFC, Bluetooth, RFID, etc.). Therefore, example communications interfaces <NUM> include NFC communication modules, Bluetooth communication modules, and/or RFID communication modules.

As stated, the system <NUM> is configured to implement key diversification to secure data, which may be referred to as a key diversification technique herein. Generally, the server <NUM> (or another computing device) and the contactless card <NUM> may be provisioned with the same master key <NUM> (also referred to as a master symmetric key). More specifically, each contactless card <NUM> is programmed with a distinct master key <NUM> that has a corresponding pair in the server <NUM>. For example, when a contactless card <NUM> is manufactured, a unique master key <NUM> may be programmed into the memory <NUM> of the contactless card <NUM>. Similarly, the unique master key <NUM> may be stored in a record of a customer associated with the contactless card <NUM> in the account data <NUM> of the server <NUM> (and/or stored in a different secure location, such as the hardware security module (HSM) <NUM>). The master key may be kept secret from all parties other than the contactless card <NUM> and server <NUM>, thereby enhancing security of the system <NUM>. In some embodiments, the applet <NUM> of the contactless card <NUM> may encrypt and/or decrypt data (e.g., the customer ID <NUM> and/or passport data <NUM>) using the master key <NUM> and the data as input a cryptographic algorithm. For example, encrypting the customer ID <NUM> with the master key <NUM> may result in the encrypted customer ID <NUM>. Similarly, the authentication server <NUM> may encrypt and/or decrypt data associated with the contactless card <NUM> using the corresponding master key <NUM>.

In other embodiments, the master keys <NUM> of the contactless card <NUM> and server <NUM> may be used in conjunction with the counters <NUM> to enhance security using key diversification. The counters <NUM> comprise values that are synchronized between the contactless card <NUM> and server <NUM>. The counter value <NUM> may comprise a number that changes each time data is exchanged between the contactless card <NUM> and the server <NUM> (and/or the contactless card <NUM> and the mobile device <NUM>). When preparing to send data (e.g., to the server <NUM> and/or the mobile device <NUM>), the contactless card <NUM> may increment the counter value <NUM>. The contactless card <NUM> may then provide the master key <NUM> and counter value <NUM> as input to a cryptographic algorithm, which produces a diversified key <NUM> as output. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of the cryptographic algorithm may include a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm, such as HMAC-SHA-<NUM>; and a symmetric CMAC algorithm such as AES-CMAC. Examples of key diversification techniques are described in greater detail in <CIT>.

Continuing with the key diversification example, the contactless card <NUM> may then encrypt the data (e.g., the customer ID <NUM> and/or any other data, such as the passport data <NUM>) using the diversified key <NUM> and the data as input to the cryptographic algorithm. For example, encrypting the customer ID <NUM> with the diversified key <NUM> may result in the encrypted customer ID <NUM>.

Regardless of the encryption technique used, the contactless card <NUM> may then transmit the encrypted data (e.g., the encrypted customer ID <NUM>) to the account application <NUM> of the mobile device <NUM> (e.g., via an NFC connection, Bluetooth connection, etc.). The account application <NUM> of the mobile device <NUM> may then transmit the encrypted customer ID <NUM> to the server <NUM> via the network <NUM>. In at least one embodiment, the contactless card <NUM> transmits the counter value <NUM> with the encrypted data. In such embodiments, the contactless card <NUM> may transmit an encrypted counter value <NUM>, or an unencrypted counter value <NUM>.

Once received, the authentication application <NUM> may authenticate the encrypted customer ID <NUM>. For example, the authentication application <NUM> may attempt to decrypt the encrypted customer ID <NUM> using a copy of the master key <NUM> stored in the memory <NUM> of the authentication server <NUM>. In another example, the authentication application <NUM> may provide the master key <NUM> and counter value <NUM> as input to the cryptographic algorithm, which produces a diversified key <NUM> as output. The resulting diversified key <NUM> may correspond to the diversified key <NUM> of the contactless card <NUM>, which may be used to decrypt the encrypted customer ID <NUM>.

Regardless of the decryption technique used, the authentication application <NUM> may successfully decrypt the encrypted customer ID <NUM>, thereby verifying the encrypted customer ID <NUM> (e.g., by comparing the resulting customer ID <NUM> to a customer ID stored in the account data <NUM>, and/or based on an indication that the decryption using the key <NUM> and/or <NUM> was successful). Although the keys <NUM>, <NUM> are depicted as being stored in the memory <NUM>, the keys <NUM>, <NUM> may be stored elsewhere, such as in a secure element and/or the HSM <NUM>. In such embodiments, the secure element and/or the HSM <NUM> may decrypt the encrypted customer ID <NUM> using the keys <NUM> and/or <NUM> and a cryptographic function. Similarly, the secure element and/or HSM <NUM> may generate the diversified key <NUM> based on the master key <NUM> and counter value <NUM> as described above.

If, however, the authentication application <NUM> is unable to decrypt the encrypted customer ID <NUM> to yield the expected result (e.g., the customer ID <NUM> of the account associated with the contactless card <NUM>), the authentication application <NUM> does not validate the encrypted customer ID <NUM>. In such an example, the authentication application <NUM> transmits an indication of the failed verification to the account application <NUM>. As such, the account application <NUM> may reject performance of the requested operation to preserve the security of the account.

<FIG> illustrates an embodiment where the authentication application <NUM> has decrypted the encrypted customer ID <NUM>, thereby verifying (or authenticating) the encrypted data. As shown, the authentication application <NUM> transmits a verification <NUM> to the mobile device <NUM>, where the verification <NUM> indicates that the authentication application <NUM> successfully decrypted the encrypted customer ID <NUM>. Responsive to receiving the verification <NUM>, the account application <NUM> may reference the rules <NUM> to determine what, if any, additional authentication steps are required. The rules <NUM> may generally specify a plurality of different authentication rules and/or thresholds for different requested operations. The rules may be based on the type of requested operation. For example, for the transfer of funds, the rules <NUM> may require additional authentication based on additional data elements such as the passport data <NUM>.

In such an example, the account application <NUM> may output an indication specifying that the user tap the contactless card <NUM> to the mobile device <NUM>. The account application <NUM> may then instruct the contactless card <NUM> to transmit the passport data <NUM>. In response, the contactless card <NUM> may transmit the passport data <NUM> to the account application <NUM>. As stated, in some embodiments, the passport data <NUM> may be encrypted. The passport data <NUM> may be encrypted using one or more attributes of the passport, such as a passport number of the user's passport, an issue date of the user's passport, and/or an expiration date of the user's passport. Although depicted as being received in a separate tap of the contactless card <NUM>, in some embodiments, the passport data <NUM> is transmitted with the encrypted user ID <NUM> in a single tap of the contactless card <NUM> to the mobile device <NUM>, e.g., the tap depicted in <FIG>.

The account application <NUM> may then receive the passport attributes for decrypting the encrypted passport data <NUM>. For example, a user may provide the passport number, expiration date, and/or issue date via a graphical user interface (GUI) of the account application <NUM>. In another embodiment, the camera <NUM> of the mobile device <NUM> may be used to capture one or more images of one or more pages of a physical version of the passport. The one or more pages may depict the attributes required to decrypt the encrypted passport data <NUM>. Therefore, the account application <NUM> may extract the passport number, expiration date, and/or issue date from the captured images, e.g., by using computer vision, optical character recognition (OCR), etc..

In the embodiment depicted in <FIG>, the account application <NUM> decrypts the encrypted passport data <NUM> using the received passport attributes. If the decryption is successful, the account application <NUM> may permit performance of the requested operation. For example, upon decrypting the passport data <NUM>, the account application <NUM> may display a GUI allowing the user to initiate the desired transfer of funds. Otherwise, the account application <NUM> may restrict performance of the requested operation, e.g., by blocking access to the GUI for transfer of funds, outputting a notification that the requested operation cannot be performed based on the failed decryption, etc..

In some embodiments, the authentication server <NUM> decrypts the encrypted passport data <NUM>. For example, <FIG> is a schematic <NUM> depicting an embodiment where the authentication server <NUM> is used to decrypt the passport data <NUM>. As shown, the user taps the contactless card <NUM> to the mobile device <NUM> to proceed with a requested operation. As stated, the user may provide authentication credentials to access the account associated with the contactless card <NUM> prior to tapping the contactless card <NUM> to the device <NUM>. For example, the requested operation may be to update account information in the account application <NUM> after providing the authentication credentials to access account details. In response to the tap, the applet <NUM> generates an encrypted customer ID <NUM>, which is transmitted to the account application <NUM> with the encrypted passport data <NUM>. Generally, the encrypted customer ID <NUM> is generated by the applet <NUM> as described above with respect to the generation of the encrypted customer ID <NUM> (e.g., by encrypting the customer ID <NUM> with the master key <NUM> and/or the diversified key <NUM>).

Responsive to receiving the encrypted customer ID <NUM> and the encrypted passport data <NUM>, the account application <NUM> may receive the passport attributes (e.g., the passport number, expiration date, and/or issue date) needed to decrypt the encrypted passport data <NUM>. For example, the user may provide the passport attributes as input in a GUI of the account application <NUM>. As another example, an image of the physical passport may be captured, and the account application <NUM> may extract the passport attributes from the captured image, e.g., by identifying the relevant fields and values in the image. Once received, the account application <NUM> may transmit the received passport attributes to the authentication server <NUM> as the passport attributes <NUM> with the encrypted customer ID <NUM> and the passport data <NUM>.

Once received, the authentication application <NUM> may attempt to decrypt the encrypted customer ID <NUM> using the master key <NUM> and/or the diversified key <NUM> as described above. If the attempted decryption yields the customer ID <NUM> associated with the account, the authentication application <NUM> may attempt to decrypt the passport data <NUM> using the passport attributes <NUM>. If the decryption of the encrypted customer ID <NUM> and the passport data <NUM> is successful, as reflected in <FIG>, the authentication application <NUM> may transmit a verification <NUM> to the account application <NUM>. The account application <NUM> may then permit the requested operation based on receipt of the verification <NUM>, which specifies that the encrypted customer ID <NUM> and the encrypted passport data <NUM> were verified (or authenticated) by the authentication server <NUM>. For example, the account application <NUM> may expose and/or enable a GUI that allows the user to modify their account details. If either attempted decryption (of the encrypted customer ID <NUM> and the encrypted passport data <NUM>) is not successful, the authentication application <NUM> may transmit an indication of the failed decryption(s) to the account application <NUM>, which may reject performance the requested operation. For example, the account application <NUM> may restrict access to the GUI (and/or disable elements thereof) that allows the user to modify their account details.

In some embodiments, the passport data <NUM> that has been encrypted using the passport attributes may further be encrypted by the applet <NUM> based on the master key <NUM> and/or the diversified key <NUM>. Therefore, in such embodiments, the authentication application <NUM> may initially decrypt the passport data <NUM> using the keys <NUM> and/or <NUM> as described above. If the initial decryption is successful, the authentication application <NUM> may attempt to decrypt the passport data <NUM> using the passport attributes <NUM>. If the decryption of the passport data <NUM> using the passport attributes <NUM> is successful, the authentication application <NUM> may transmit the verification <NUM> to the account application <NUM>, which may authorize the requested operation.

Regardless of the entity decrypting the passport data <NUM>, in at least one embodiment, the applet <NUM> of the contactless card <NUM> may generate a digital signature (not pictured) for the passport data <NUM> using the keys <NUM> and/or <NUM>. The digital signature may sign the passport data <NUM>. The contactless card <NUM> may then transmit the digital signature with the passport data <NUM> to the account application <NUM>, which in turn transmits the digital signature to the authentication server <NUM>. The authentication application <NUM> may also verify the digital signature by decrypting the digital signature using a public key associated with the contactless card <NUM> and stored by the server <NUM>. If the digital signature is verified, the authentication application <NUM> may transmit an indication of the successful digital signature verification to the account application <NUM>, which may permit performance of the operation based on verification of the digital signature. If the digital signature is not verified, the account application <NUM> may restrict performance of the operation.

Regardless of the entity decrypting the passport data <NUM>, in some embodiments, the account application <NUM> may determine a level of access permissions specified by the rules <NUM> required to perform the operation. For example, the rules <NUM> may require that the user have a "high" security level to perform the requested operation (e.g., transfer of funds). However, the user's account data <NUM> (which may be stored locally in the account application <NUM> and/or received from the server <NUM>) may specify that the user has a "medium" level of security. In such embodiments, the account application <NUM> may transmit a request for an updated permissions level to the server <NUM>. In response, the authentication application <NUM> may determine to update the user's permissions level to "high" based on the decryption of the encrypted customer ID <NUM> and the passport data <NUM>. In such an embodiment, the authentication application <NUM> may transmit the updated permissions level to the account application <NUM>, which permits the requested operation based on the updated permissions level meeting the permissions level required by the rules <NUM>.

Furthermore, in some embodiments, the user may obtain a new and/or updated passport. In such embodiments, the account application <NUM> may receive the new and/or updated versions of the passport data <NUM>, e.g., from the authentication server <NUM>. In such embodiments, the account application <NUM> may transmit the updated passport data received from the server <NUM> to the contactless card <NUM>, and the applet <NUM> may store the received data in the memory <NUM>.

<FIG> is a schematic <NUM> depicting an example embodiment of tapping the contactless card <NUM> to provide secure authentication based on the passport data <NUM> stored in the contactless card <NUM>. As shown, the account application <NUM> may receive a request to perform an operation. For example, the request may be to transfer funds from one account to another account. The account application <NUM> may reference the rules <NUM> to determine which type of data is required to authorize the requested transfer of funds. For example, the rules <NUM> may specify that fund transfers require verification of the encrypted customer ID and verification based on the passport data <NUM>. In at least one embodiment, the type of data specified by the rules <NUM> is based on the type of requested operation (e.g., the transfer of funds). Generally, the rules <NUM> may specify different levels of security for different types of transaction (e.g., requiring verification of passport data <NUM> for higher risk operations, while not requiring verification of the passport data <NUM> for lower risk operations).

In response, the account application <NUM> may output an indication to tap the contactless card <NUM> to the device <NUM>. Once the user taps the contactless card <NUM> to the mobile device <NUM>, the applet <NUM> of the contactless card <NUM> encrypts the customer ID <NUM> (e.g., to produce the encrypted customer IDs <NUM> and/or <NUM>). The applet <NUM> may then transmit the encrypted customer ID <NUM> and the encrypted passport data <NUM> to the mobile device <NUM>, e.g., via NFC.

As shown in the schematic <NUM> of <FIG>, the account application <NUM> may output an indication specifying that the user take a photo of one or more pages of their physical passport using the camera <NUM>. The user may then capture an image of the passport. The account application <NUM> may then process the captured image to extract one or more attributes of the passport, such as the passport number, issue date, and expiration date.

As stated, in some embodiments, the account application <NUM> may decrypt the encrypted passport data <NUM> using the attributes extracted from the image. In other embodiments, such as the embodiments of <FIG>, the authentication application <NUM> may decrypt the encrypted passport data <NUM> using the attributes extracted by the account application <NUM>. Therefore, the account application <NUM> may transmit the encrypted customer ID <NUM>, the encrypted passport data <NUM>, and the extracted attributes of the passport to the authentication application <NUM>.

The authentication application <NUM> may then attempt to decrypt the encrypted customer ID <NUM> (and/or the encrypted passport data <NUM>) using the master key <NUM> and/or the diversified key <NUM> associated with the contactless card <NUM>. If the authentication application <NUM> is unable to decrypt the encrypted customer ID <NUM> to yield an expected result (e.g., the customer ID <NUM> of the account, etc.), the authentication application <NUM> does not verify the encrypted customer ID <NUM>. If the authentication application <NUM> successfully decrypts the encrypted customer ID <NUM> to yield an expected result (e.g., the customer ID <NUM> of the account, etc.), the authentication application <NUM> verifies the encrypted customer ID <NUM> and attempts to decrypt the passport data <NUM> using the attributes received from the account application <NUM>. If the authentication application <NUM> successfully decrypts the passport data <NUM>, the account application <NUM> transmits an indication of the verification of the encrypted customer ID <NUM> and the encrypted passport data <NUM> to the account application <NUM>. The account application <NUM> may then permit performance of the requested operation responsive to receiving the verification.

If, however, the authentication application <NUM> is unable to decrypt the encrypted customer ID <NUM> and/or the encrypted passport data <NUM>, the authentication application <NUM> transmits an indication of the failed decryption(s) to the account application <NUM>. The account application <NUM> may then restrict performance of the requested operation, e.g., by disabling the "Next" button depicted in <FIG>.

As stated, in some embodiments, the rules <NUM> specify a permissions level required to perform the associated operation. For example, to update the account details, the rules <NUM> may require a permissions level greater than or equal to <NUM> on a scale from <NUM>-<NUM>. Therefore, in such embodiments, the account application <NUM> may transmit the user's current permissions level to the authentication application <NUM>. The current permissions level may be stored locally by the account application <NUM> (e.g. in an instance of the account data <NUM> stored in the memory <NUM> of the mobile device <NUM>) and/or received from the authentication application <NUM> (e.g., when the user logs into the account application <NUM> using authentication credentials).

In such examples, the user's current permissions level may be <NUM>. Therefore, the account application <NUM> may transmit an indication to the authentication application <NUM> specifying that the user's current permissions level does not meet the required permissions level. The authentication application <NUM> may then determine whether to increase the user's permissions level. For example, based on the authentication application <NUM> successfully decrypting the encrypted customer ID <NUM> and the encrypted passport data <NUM>, the authentication application <NUM> may increase the user's permissions level to <NUM>. The authentication application <NUM> may transmit an indication of the new permissions level to the account application <NUM> with the verification. The account application <NUM> may then permit the performance of the requested operation responsive to receiving the verification from the authentication server <NUM> and based on the updated permissions level exceeding the permissions level specified in the rules <NUM>.

<FIG> illustrates a contactless card <NUM>, which may comprise a payment card, such as a credit card, debit card, and/or a gift card. As shown, the contactless card <NUM> may be issued by a service provider <NUM> displayed on the front or back of the card <NUM>. In some examples, the contactless card <NUM> is not related to a payment card, and may comprise, without limitation, an identification card. In some examples, the payment card may comprise a dual interface contactless payment card. The contactless card <NUM> may comprise a substrate <NUM>, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card <NUM> may have physical characteristics compliant with the ID-<NUM> format of the ISO/IEC <NUM> standard, and the contactless card may otherwise be compliant with the ISO/IEC <NUM> standard. However, it is understood that the contactless card <NUM> according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card.

The contactless card <NUM> may also include identification information <NUM> displayed on the front and/or back of the card, and a contact pad <NUM>. The contact pad <NUM> may be configured to establish contact with another communication device, such as the mobile devices <NUM>, a user device, smart phone, laptop, desktop, or tablet computer. The contactless card <NUM> may also include processing circuitry, antenna and other components not shown in <FIG>. These components may be located behind the contact pad <NUM> or elsewhere on the substrate <NUM>. The contactless card <NUM> may also include a magnetic strip or tape, which may be located on the back of the card (not shown in <FIG>).

As illustrated in <FIG>, the contact pad <NUM> of contactless card <NUM> may include processing circuitry <NUM> for storing and processing information, including a microprocessor <NUM> and the memory <NUM>. It is understood that the processing circuitry <NUM> may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper proofing hardware, as necessary to perform the functions described herein.

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

The memory <NUM> may be configured to store one or more applets <NUM>, the counter <NUM>, master key <NUM>, the diversified key <NUM>, one or more customer (or user) IDs <NUM>, and the passport data <NUM>. The one or more applets <NUM> may comprise one or more software applications configured to execute on one or more contactless cards, such as a Java® Card applet. However, it is understood that applets <NUM> are not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory. The customer ID <NUM> may comprise a unique alphanumeric identifier assigned to a user of the contactless card <NUM>, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer ID <NUM> may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account. In some embodiments, the applet <NUM> may use the customer ID <NUM> as input to a cryptographic algorithm with the keys <NUM> and/or <NUM> to encrypt the customer ID <NUM>. Similarly, the applet <NUM> may use the passport data <NUM> (which may be unencrypted and/or encrypted based on one or more attributes of the passport <NUM>) as input to a cryptographic algorithm with the keys <NUM> and/or <NUM> to encrypt the passport data <NUM>.

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

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

In an embodiment, the coil of contactless card <NUM> may act as the secondary of an air core transformer. The terminal may communicate with the contactless card <NUM> by cutting power or amplitude modulation. The contactless card <NUM> may infer the data transmitted from the terminal using the gaps in the contactless card's power connection, which may be functionally maintained through one or more capacitors. The contactless card <NUM> may communicate back by switching a load on the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil through interference. More generally, using the antennas <NUM>, processing circuitry <NUM>, and/or the memory <NUM>, the contactless card <NUM> provides a communications interface to communicate via NFC, Bluetooth, and/or Wi-Fi communications.

As explained above, contactless cards <NUM> may be built on a software platform operable on smart cards or other devices having limited memory, such as JavaCard, and one or more or more applications or applets may be securely executed. Applets may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., the communications interface <NUM> of the device <NUM>), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag.

Operations for the disclosed embodiments may be further described with reference to the following figures. Some of the figures may include a logic flow. Although such figures presented herein may include a particular logic flow, it can be appreciated that the logic flow merely provides an example of how the general functionality as described herein can be implemented. Further, a given logic flow does not necessarily have to be executed in the order presented unless otherwise indicated. In addition, the given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof.

<FIG> illustrates an embodiment of a logic flow <NUM>. The logic flow <NUM> may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow <NUM> may include some or all of the operations to use the contactless card <NUM> to provide secure authentication based on passport data stored in the contactless card <NUM>. Embodiments are not limited in this context.

As shown, the logic flow <NUM> begins at block <NUM>, where the account application <NUM> receives a request to perform an operation. As stated, the requested operation may be received based on input from a user of the account application <NUM>, an external source (e.g., one of the other applications <NUM>), or any other source. The request may be related to, for example and without limitation, use of the account application <NUM>, use of the other applications <NUM>, operations related to the account associated with the contactless card <NUM>, and/or a transaction. More generally, the request may be received subsequent to a user providing authentication credentials required to access the account in the account application <NUM>. At block <NUM>, a user taps the contactless card <NUM> to the mobile device <NUM> to cause the applet <NUM> of the contactless card <NUM> to encrypt the customer ID <NUM> and transmit the encrypted customer ID to the mobile device <NUM>.

At block <NUM>, the account application <NUM> may receive the encrypted customer ID from the contactless card <NUM>. The account application <NUM> may then transmit the encrypted customer ID received from the contactless card <NUM> to the authentication server <NUM>. The server <NUM> may attempt to decrypt the encrypted customer ID as described herein. At block <NUM>, the account application <NUM> receives an indication from the server <NUM> that the encrypted customer ID was verified by decrypting the encrypted customer ID <NUM>.

At block <NUM>, the account application <NUM> determines a type of the request, which may be used to determine a type of verification data specified in the rules <NUM> required to authorize the type of operation. For example, the passport data <NUM> may be specified as the verification data required by the rules <NUM>. At block <NUM>, the user taps the contactless card <NUM> to the mobile device <NUM>. Doing so instructs the applet <NUM> of the contactless card <NUM> to transmit the passport data <NUM> to the mobile device <NUM>. The account application <NUM> may then receive the passport data <NUM> from the contactless card <NUM>. However, as stated, in some embodiments, the passport data <NUM> may be received at block <NUM> responsive to the tap at block <NUM>.

At block <NUM>, the account application <NUM> may receive the passport attributes. For example, a user may provide the passport attributes as input to the account application <NUM>. As another example, the account application <NUM> may instruct the user to capture an image of the passport page including the passport attributes. The account application <NUM> may then extract the attributes from the captured image, e.g., by identifying values associated with each passport attribute in the captured image. At block <NUM>, the account application <NUM> may successfully decrypt the passport data <NUM> using the attributes received at block <NUM>. As stated, however, in some embodiments, the account application <NUM> transmits the passport data <NUM> and the extracted attributes to the authentication application <NUM> for decryption. In such embodiments, the account application <NUM> may transmit the passport data <NUM> and extracted attributes with an encrypted customer ID generated by the contactless card <NUM>. The authentication application <NUM> may then attempt to decrypt the customer ID and the passport data <NUM> and inform the account application <NUM> whether the decryption attempts were successful or unsuccessful.

At block <NUM>, the account application <NUM> permits performance of the requested operation based on the verification of the encrypted customer ID by the server <NUM> and the decryption of the encrypted passport data <NUM>. At block <NUM>, the requested operation may be performed, e.g., by the user and/or by the account application <NUM>.

<FIG> illustrates an embodiment of a logic flow <NUM>. The logic flow <NUM> may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow <NUM> may include some or all of the operations to receive passport attributes to decrypt the passport data <NUM> stored in the contactless card <NUM>. Embodiments are not limited in this context.

As shown, the logic flow <NUM> begins at block <NUM>, where the account application <NUM> optionally receives text-based input from a user specifying the passport attributes. As stated, the passport attributes may include the passport number, passport issue date, and passport expiration date. However, other data may be used for encryption/decryption of the passport data <NUM>, such as the person's name or other information. More generally, the account application <NUM> may be aware of the required attributes and/or attribute types. At block <NUM>, the account application <NUM> outputs an instruction to the user to capture an image depicting a page of the physical passport corresponding to the passport data <NUM>. At block <NUM>, the account application <NUM> receives the image captured by the camera <NUM> of the mobile device <NUM>.

At block <NUM>, the account application <NUM> extracts the attributes from the captured image. For example, the account application <NUM> may apply one or more image processing algorithms to extract the attributes. Generally, by being programmed to identify the required passport attributes, the account application <NUM> may process the image to identify the required attributes and extract the values associated with each attribute. For example, by recognizing text in the image, the account application <NUM> may identify the "Passport Number" or some variant thereof in the text of the image. The account application <NUM> may then extract the value (e.g., numeric and/or alphanumeric values) associated with the identified phrase. For example, the account application <NUM> may be programmed with information describing the layout of the passport. Therefore, the account application <NUM> may determine where in the image to extract the relevant attribute names, and where in the image to extract the relevant values.

<FIG> illustrates an embodiment of a logic flow <NUM>. The logic flow <NUM> may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow <NUM> may include some or all of the operations to authorize requested operations using the passport data <NUM> stored in the contactless card <NUM>. Embodiments are not limited in this context.

As shown, the logic flow <NUM> begins at block <NUM>, where the account application <NUM> receives authentication credentials associated with an account. At block <NUM>, the account application <NUM> determines a current permissions level of the account (and/or the user associated with the account). At block <NUM>, the account application <NUM> determines that the rules <NUM> specify a permissions level that exceed the current permissions level of the user. The permissions level specified by the rules <NUM> may be for an operation requested to be performed by the user (e.g., the operation requested at block <NUM> of the logic flow <NUM>).

At block <NUM>, the account application <NUM> transmits an indication to the authentication application <NUM> specifying that the account application <NUM> has decrypted the passport data <NUM> (e.g., at block <NUM> of the logic flow <NUM>). At block <NUM>, the authentication application <NUM> updates the permissions level of the user. The authentication application <NUM> may update the permissions level based on the indication specifying that the passport data <NUM> was decrypted and determining that the authentication application <NUM> verified encrypted data generated by the contactless card <NUM>. For example, the authentication application <NUM> may set a timer responsive to validating the encrypted customer ID <NUM> at block <NUM> of the logic flow <NUM>. If the authentication application <NUM> receives the indication at block <NUM> before the timer exceeds a time threshold, the authentication application <NUM> may determine to update the permissions level and transmit the updated permissions level to the account application <NUM>.

At block <NUM>, the account application <NUM> receives the updated permissions level from the server <NUM>. At block <NUM>, the account application <NUM> determines that the updated permissions level received at block <NUM> meets or exceeds the permissions level specified for the operation by the rules <NUM>. In response, the account application <NUM> may permit performance of the operation.

<FIG> illustrates an embodiment of an exemplary computing architecture <NUM> comprising a computing system <NUM> that may be suitable for implementing various embodiments as previously described. In various embodiments, the computing architecture <NUM> may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture <NUM> may be representative, for example, of a system that implements one or more components of the system <NUM>. In some embodiments, computing system <NUM> may be representative, for example, of the contactless card <NUM>, mobile devices <NUM>, and authentication server <NUM> of the system <NUM>. More generally, the computing architecture <NUM> is configured to implement all logic, applications, systems, methods, apparatuses, and functionality described herein with reference to <FIG>.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

The computing system <NUM> includes various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth. The embodiments, however, are not limited to implementation by the computing system <NUM>.

As shown in <FIG>, the computing system <NUM> comprises a processor <NUM>, a system memory <NUM> and a system bus <NUM>. The processor <NUM> can be any of various commercially available computer processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core®, Core (<NUM>) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi processor architectures may also be employed as the processor <NUM>.

The system bus <NUM> provides an interface for system components including, but not limited to, the system memory <NUM> to the processor <NUM>.

The system memory <NUM> may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.

The computing system <NUM> may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) <NUM>, a magnetic floppy disk drive (FDD) <NUM> to read from or write to a removable magnetic disk <NUM>, and an optical disk drive <NUM> to read from or write to a removable optical disk <NUM> (e.g., a CD-ROM or DVD). The HDD <NUM>, FDD <NUM> and optical disk drive <NUM> can be connected to the system bus <NUM> by a HDD interface <NUM>, an FDD interface <NUM> and an optical drive interface <NUM>, respectively. The HDD interface <NUM> for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE <NUM> interface technologies. The computing system <NUM> is generally is configured to implement all logic, systems, methods, apparatuses, and functionality described herein with reference to <FIG>.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-readable instructions, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units <NUM>, <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM>, and program data <NUM>. In one embodiment, the one or more application programs <NUM>, other program modules <NUM>, and program data <NUM> can include, for example, the various applications and/or components of the system <NUM>, e.g., the applet <NUM>, counter104, master key <NUM>, diversified key <NUM>, customer ID <NUM>, passport data <NUM>, encrypted customer ID <NUM>, operating system <NUM>, account application <NUM>, other applications <NUM>, the authentication application <NUM>, the account data <NUM>, the encrypted customer ID <NUM>, and/or the passport attributes <NUM>.

A user can enter commands and information into the computing system <NUM> through one or more wire/wireless input devices, for example, a keyboard <NUM> and a pointing device, such as a mouse <NUM>. Other input devices may include microphones, infrared (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processor <NUM> through an input device interface <NUM> that is coupled to the system bus <NUM>, but can be connected by other interfaces such as a parallel port, IEEE <NUM> serial port, a game port, a USB port, an IR interface, and so forth.

The monitor <NUM> may be internal or external to the computing system <NUM>.

The computing system <NUM> may operate in a networked environment using logical connections via wire and/or wireless communications to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computing system <NUM>, although, for purposes of brevity, only a memory/storage device <NUM> is illustrated. In embodiments, the network <NUM> of <FIG> is one or more of the LAN <NUM> and the WAN <NUM>.

When used in a LAN networking environment, the computing system <NUM> is connected to the LAN <NUM> through a wire and/or wireless communication network interface or adaptor <NUM>.

When used in a WAN networking environment, the computing system <NUM> can include a modem <NUM>, or is connected to a communications server on the WAN <NUM>, or has other means for establishing communications over the WAN <NUM>, such as by way of the Internet. The modem <NUM>, which can be internal or external and a wire and/or wireless device, connects to the system bus <NUM> via the input device interface <NUM>. In a networked environment, program modules depicted relative to the computing system <NUM>, or portions thereof, can be stored in the remote memory/storage device <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

The computing system <NUM> is operable to communicate with wired and wireless devices or entities using the IEEE <NUM> family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE <NUM> over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE <NUM>. 11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE <NUM>-related media and functions).

Such representations, known as "IP cores" may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that make the logic or processor. Some embodiments may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

Claim 1:
A system, comprising:
a processor; and
a memory storing instructions which when executed by the processor cause the processor to:
receive, by an application (<NUM>) executing on the processor, a request to perform an operation associated with an account;
receive, by the application (<NUM>), encrypted data (<NUM>) from a contactless card (<NUM>) associated with the account, the encrypted data (<NUM>) based on a cryptographic algorithm, a customer identifier (<NUM>), and a master key (<NUM>) for the contactless card (<NUM>);
transmit, by the application (<NUM>), the encrypted data (<NUM>) to an authentication server (<NUM>);
receive, by the application from the authentication server (<NUM>), an indication specifying that the authentication server (<NUM>) verified the encrypted data based on the master key (<NUM>) for the contactless card (<NUM>);
receive, by the application (<NUM>), encrypted passport data (<NUM>) from the contactless card (<NUM>), the encrypted passport data (<NUM>) for a passport of a user associated with the contactless card (<NUM>), the encrypted passport data (<NUM>) encrypted based on at least one attribute of the passport;
determine, by the application (<NUM>), the at least one attribute of the passport based at least in part on image data or text input;
decrypt, by the application (<NUM>), the encrypted passport data (<NUM>) based on the at least one attribute of the passport; and
initiate performance of the operation based on the received indication specifying that the authentication server (<NUM>) verified the encrypted data (<NUM>) and the decryption of the encrypted passport data (<NUM>).