Remote authentication using near field communication tag

An apparatus comprises a processing device comprising NFC interface circuitry, network interface circuitry, a memory and a processor coupled to the memory. The processing device is configured to establish an NFC connection with an NFC tag using the NFC interface circuitry, establish a network connection with an authentication server using the network interface circuitry, and forward one or more messages between the NFC tag and the authentication server, the one or more messages comprising messages of a challenge/response authentication protocol performed between the NFC tag and the authentication server. Responsive to a successful completion of the challenge/response authentication protocol between the NFC tag and the authentication server, the processing device is authenticated to the authentication server.

FIELD

The present invention relates generally to cryptography, and more particularly to authentication techniques.

BACKGROUND

Near field communication (NFC) is a set of standards for smartphones and other processing devices for establishing radio communication with one another by touching them together or bringing them into close proximity, typically on a range of a few centimeters. NFC operates at 13.56 MHz on the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 18000-3 air interface at rates ranging from approximately 106 kbit/s to 424 kbits/s. NFC typically involves an initiator and a target. In some arrangements, the initiator actively generates a radio frequency (RF) field that powers a passive target. This allows NFC targets to take very simple form factors that do not require batteries.

An NFC target may comprise a microchip with small aerials which is capable of storing a small amount of information for transfer to an NFC initiator. Devices with NFC capability are becoming generally available. Examples of such devices include smartphones, tablets, laptops and other computing and processing devices.

SUMMARY

In one embodiment, an apparatus comprises a processing device comprising NFC interface circuitry, network interface circuitry, a memory and a processor coupled to the memory. The processing device is configured to establish an NFC connection with an NFC tag using the NFC interface circuitry, establish a network connection with an authentication server using the network interface circuitry, and forward one or more messages between the NFC tag and the authentication server, the one or more messages comprising messages of a challenge/response authentication protocol performed between the NFC tag and the authentication server. Responsive to a successful completion of the challenge/response authentication protocol between the NFC tag and the authentication server, the processing device is authenticated to the authentication server.

In another embodiment, an apparatus comprises an authentication server comprising network interface circuitry, a memory and a processor coupled to a memory. The authentication server is configured to establish a network connection with a processing device using the network interface circuitry, perform a challenge/response authentication protocol with an NFC tag connected to the processing device by sending to and receiving from the processing device over the network connection one or more messages for the challenge/response authentication protocol, and authenticate the processing device responsive to a successful completion of the challenge/response authentication protocol with the NFC tag.

These and other features and advantages of embodiments of the present invention will become more readily apparent from the accompanying drawings and the following detailed description.

DETAILED DESCRIPTION

Illustrative embodiments of the present invention will be described herein with reference to exemplary communication systems and associated servers, NFC devices and other processing devices. It is to be appreciated, however, that the invention is not restricted to use with the particular illustrative system and device configurations shown. Accordingly, the term “communication system” as used herein is intended to be broadly construed, so as to encompass, for example, systems in which multiple processing devices communicate with one another but not necessarily in a manner characterized by a client-server model.

Cryptographically capable NFC tags support strong mutual authentication between the tag and a tag reader. The term NFC tag as used herein is intended to be construed broadly to encompass any device with NFC capability. A device with NFC capability may be a standalone NFC device, a device with NFC circuitry embodied therein, a device with removable NFC circuitry, etc. An NFC tag may take on a variety of form factors, which include but are not limited to form factors such as a card, sticker, key fob, token and various other small and lightweight processing devices.

Embodiments of the invention enable a user to authenticate to a remote server responsive to a successful completion of an authentication protocol between an NFC tag and the remote server. The user, through a processing device which relays or otherwise forwards messages between an NFC tag and remote server, is authenticated to the remote server responsive to a successful completion of the challenge/response authentication protocol. One or more messages in the authentication protocol are encrypted using a key shared by the NFC tag and the remote server. The user does not have knowledge of the shared key, and thus cannot decrypt the messages forwarded between the NFC tag and the remote server in the authentication protocol. The messages forwarded by the processing device may be bound to an identity of the user and/or processing device for added security. Embodiments may utilize built-in authentication protocols of an NFC tag which are suitably modified to function as described herein.

An example of an NFC tag with built-in authentication protocols is the MIFARE DESFire™ EV1 token produced by NXP Semiconductors. The MIFARE DESFire™ EV1 has a number of selectable cryptographic methods, including 2-Key Triple Data Encryption Standard (2KTDES), 3-Key Triple Data Encryption Standard (3KTDES) and 128-bit Advanced Encryption Standard (AES128). An NFC tag used in embodiments of the invention may be a suitably modified MIFARE DESFire™ EV1 token.

FIG. 1illustrates a communication system100. The communication system100includes an authentication server102, a user device104and an NFC tag106. The NFC tag106and the authentication server102have a shared key120stored in respective memories therein. It is important to note that an NFC tag106may store a plurality of shared keys for use in authenticating to a plurality of authentication servers or respective keys for various applications which require access to protected resources. For example, the MIFARE DESFire™ EV1 token supports up to 28 applications, with each application having its own key. Thus, a single MIFARE DESFire™ EV1 token may support up to 28 independent authentication applications. It will be appreciated that various other NFC tags may have different numbers of shared keys stored therein, and may in some instances have more than one shared key which corresponds to a single authentication application.

The authentication server102comprises a remote authentication module122. The NFC tag106comprises a remote authentication module162. The remote authentication modules122and162may comprise respective hardware, software or combinations of hardware and software which may be utilized for carrying out a challenge/response authentication protocol between the authentication server102and the NFC tag106. The user device104comprises a message forwarding module142. The message forwarding module142may comprise hardware, software or combinations of hardware and software which may be utilized for forwarding messages and other communications in a challenge/response protocol carried out between authentication server102and NFC tag106.

It is important to note that althoughFIG. 1illustrates a communication system100with only single instances of the authentication server102, user device104and NFC tag106, embodiments are not limited solely to this arrangement. As described above, an NFC tag106may store a number of shared keys for use with different authentication applications. Thus, a user device104and NFC tag106may communicate with two or more authentication servers. In addition, a given authentication server102may communicate with a number of user devices and/or NFC tags.

In some embodiments, the NFC tag106may store a first set of shared keys for use with user device104and one or more additional sets of keys for other user devices. A user or owner of the NFC tag106may use the NFC tag106with a number of different processing devices interchangeably, such as the user's smartphone and the user's tablet. The NFC tag106may store shared keys which are associated with the user or owner only, with one or more particular processing devices, or with combinations of one or more particular users and processing devices. In other embodiments, shared keys stored in the NFC tag106may not be associated with any particular user or processing device.

FIG. 2illustrates a challenge/response authentication process which is carried out in the communication system100ofFIG. 1. The challenge/response authentication process begins with the authentication server102sending a message to the user device104for forwarding to the NFC tag indicating the start of the authentication process and specifying a particular key number (KeyNo). The authentication server102and the NFC tag106may each store shared keys in the form of AES key220. The AES key220may include one or more 128-bit AES keys. It is important to note, however, that various other types of keys may be utilized in embodiments of the invention.

The message Authenticate (KeyNo) specifies a given one of the AES keys stored on the NFC tag106and the authentication server102for use in encrypting subsequent communications for the authentication protocol. In some embodiments, the AES Key220may be pre-provisioned in the NFC tag106and periodically updated in a key update or key rotation process. The key update process may take place after a certain number of authentication protocols or at particular time intervals.

The user device104receives the message Authenticate (KeyNo) from the authentication server102, and forwards this message to the NFC tag106. The NFC tag106generates a random number RndB, and encrypts RndB with KeyNo resulting in EKKeyNo(RndB). The NFC tag106sends EKKeyNo(RndB) to the user device104for forwarding to the authentication server102. The user device104receives EKKeyNo(RndB) from the NFC tag106and forwards EKKeyNo(RndB) to the authentication server102.

The authentication server102decrypts the message EKKeyNo(RndB) using KeyNo to obtain RndB. The authentication server102then generates a random number RndA, and encrypts a concatenation of RndA and a derivative of RndB denoted RndB′ using KeyNo resulting in EKKeyNo(RndA∥RndB′). In some embodiments, one or more bytes in RndB may be shifted so as to obtain RndB′. Various other approaches, however, may be utilized to derive RndB′ from RndB. In addition, in some embodiments the authentication server102does not encrypt a concatenation of RndA and RndB′ and instead may encrypt a concatenation of RndA and RndB using KeyNo.

The authentication server102sends EKKeyNo(RndA∥RndB′) to user device104for forwarding to the NFC tag106. The user device104receives EKKeyNo(RndA∥RndB′) and forwards EKKeyNo(RndA∥RndB′) to the NFC tag106.

The user device104receives EKKeyNo(RndA) and forwards EKKeyNo(RndA) to the authentication server. The authentication server102decrypts EKKeyNo(RndA) to obtain RndA. The obtained RndA is compared with the generated RndA to validate the obtained RndA. If the obtained RndA matches the generated RndA, the authentication server102authenticates the NFC tag106. The fact that the NFC tag106was able to decrypt EKKeyNo(RndA∥RndB′) authenticates the NFC tag106to the authentication server102.

In embodiments of the invention, after a successful authentication protocol between the authentication server102and the NFC tag106, the user device104is authenticated to the authentication server102. A session key may be established for future secure communications between the authentication server102and the NFC tag106and/or the user device104. The session key may be based at least in part on RndA and RndB. The session key may be utilized in a subsequent key update or key rotation process to update one or more keys stored on the NFC tag106.

FIG. 3illustrates another challenge/response authentication process which is carried out in the communication system100ofFIG. 1. The challenge/response authentication process ofFIG. 3is similar to that ofFIG. 2and provides device binding.

The challenge/response authentication process ofFIG. 3begins with the authentication server102sending a message to the user device104for forwarding to the NFC tag indicating the start of the authentication process and specifying a particular key number (KeyNo).

The user device104receives the message Authenticate (KeyNo) from the authentication server102, and forwards this message to the NFC tag106. The NFC tag106generates a random number RndB, and encrypts RndB with KeyNo resulting in EKKeyNo(RndB). The NFC tag106sends EKKeyNo(RndB) to the user device104for forwarding to the authentication server102.

The user device104and the authentication server102each have stored therein a device key DK322. The device key DK322can be used for binding the identity of the user device104to messages which are forwarded from the NFC tag106to the authentication server102. The authentication server102can verify that the user device104forwarded the messages by determining whether the user device has knowledge of the device key DK322. In the authentication process ofFIG. 3, the user device104calculates a keyed hash of the message, HMACDK, using the device key DK322. The keyed hash HMACDKis appended to the original message EKKeyNo(RndB) received from the NFC tag106. The user device104then forwards EKKeyNo(RndB)∥HMACDKto the authentication server102.

The authentication server102receives EKKeyNo(RndB)∥HMACDKfrom the user device104. The authentication server102verifies the keyed hash HMACDKto ensure that the message was received from a trusted user device104(i.e., a user device with knowledge of the device key DK322). After verifying the keyed hash HMACDK, the authentication server102decrypts the message EKKeyNo(RndB) using KeyNo to obtain RndB. Next, the authentication server102generates a random number RndA, and encrypts a concatenation of RndA and a derivative of RndB denoted RndB′ using KeyNo resulting in EKKeyNo(RndA∥RndB′). The authentication server102sends EKKeyNo(RndA∥RndB′) to user device104for forwarding to the NFC tag106. The user device104receives EKKeyNo(RndA∥RndB′) and forwards EKKeyNo(RndA∥RndB′) to the NFC tag106.

The user device104receives EKKeyNo(RndA) and calculates a keyed hash HMACDKof EKKeyNo(RndA) using the device key DK322. The keyed hash HMACDKis appended to EKKeyNo(RndA). The user device104then forwards EKKeyNo(RndA)∥HMACDKto the authentication server102.

The authentication server102receives EKKeyNo(RndA)∥HMACDKfrom the user device104. The authentication server102verifies the keyed hash HMACDKto ensure that the message was received from a trusted user device104with knowledge of the device key DK322. After verifying the keyed hash HMACDK, the authentication server102decrypts the message EKKeyNo(RndA) using KeyNo to obtain RndA. The obtained RndA is compared with the generated RndA to validate the obtained RndA. If the obtained RndA matches the generated RndA, the authentication server102authenticates the user device104and the NFC tag106. The fact that the NFC tag106was able to decrypt EKKeyNo(RndA∥RndB′) authenticates the NFC tag106to the authentication server102.

The user device104is authenticated to the authentication server102by virtue of the successful completion of the challenge/response protocol between the authentication server102and the NFC tag106. With device binding using the device key DK322, the authentication server102can ensure that the user device104which forwards messages from the NFC tag106is a trusted user device. A session key may be established for future secure communications between the authentication server102and the NFC tag106and/or the user device104. The session key may be based at least in part on RndA and RndB. The session key may be utilized in a subsequent key update process to update one or more keys stored on the NFC tag106.

FIG. 4shows a possible implementation of the communication system100ofFIG. 1.FIG. 4shows communication system400, including user device104, NFC tag106, authentication server102and third party server430. The authentication server102comprises an outfacing authentication server410, key server A412and key server B414. The user device104comprises an authentication application401and a third party application403.

The third party application403is an application which requires a protected resource from the third party server430. To access the protected resource, the user device104must authenticate to the third party server430. The third party application403may be a software application which is installed on the user device104. The third party application403may alternatively by a web application running in a browser on the user device104, a native application, a virtual private network (VPN) application, or a mobile device management (MDM) application. It is to be appreciated that various other application types may be utilized, including combinations of application types. In addition, whileFIG. 4shows only a single third party application403on the user device104, a user device104may run two or more independent third party applications at a given time.

As described above, the third party server430hosts a protected resource. The third party server430may be a web server, a VPN server, etc. The user device104may authenticate to the third party server430as part of a single sign-on scheme. Protocols such as OAuth may be used for such authentication.

The authentication application401is configured to authenticate a user on behalf of the third party application403. The authentication application401acts as an interface or middle man between the NFC tag106and the authentication server102.

Authentication server102performs the challenge/response protocol with the NFC tag106. The authentication server102includes an outfacing authentication server410, and key server A412and key server B414coupled to the outfacing authentication server410. The outfacing authentication server410manages communications with authentication server102, and provides interfaces for authentication and key provisioning procedures as well as an interface for the third party server430. The third party server430can query the authentication server102to determine if a particular third party application403or user device104is authenticated.

Key server A412and key server B414store key information for challenge/response authentications to be performed with the NFC tag106. Storing the key information separate from the outfacing authentication server410can help prevent attacks on the outfacing authentication server410. The key servers412and414are independent of one another. In some embodiments, a successful completion of the challenge/response authentication protocol with the NFC tag106requires both key server A412and key server B414to authenticate the NFC tag106and user device104using independent keys. In these embodiments, breaking into or otherwise comprising a single one of key server A412and key server B414will not compromise the system. In other embodiments, one of the key servers may be selected randomly to authenticate the NFC tag106or may serve as a backup key server to the other. Key server A412and/or key server B414perform cryptographic operations for the challenge/response authentication protocol with the NFC tag106. The results of the cryptographic operations are forwarded to the outfacing authentication server410.

The NFC tag106stores a set of keys in a memory therein. The set of keys may include independent keys for each of key server A412and key server B414. Each of the independent keys may further comprise a number of application-specific keys for each of key server A412and key server B414. For example, the user device104may run two or more independent third party applications which interface with two or more independent third party servers. Different keys may be utilized for authenticating the two or more independent third party applications. In other embodiments, a single sign-on scheme may be utilized. In these embodiments, the NFC tag106does not require separate keys for each third party application.

An authentication flow which may be utilized in the communication system400will now be described. When the third party application403seeks to access a protected resource on the third party server430which requires authentication, the third party application403can launch the authentication application401on the user device104with a callback uniform resource locator (URL). The callback URL can be registered on the authentication server102and trusted. The authentication application401launches and prompts a user of the user device104to tap or otherwise activate the NFC tag106to initiate the challenge/response authentication. The NFC tag106may carry out a challenge/response authentication protocol with the authentication server102in a manner similar to that described above with respect toFIG. 2orFIG. 3. As described above, in some embodiments a challenge/response authentication protocol may comprise a first challenge/response authentication performed with a key stored on key server A412and a second challenge/response authentication performed with a different key stored on key server B414.

After a successful completion of the challenge/response authentication protocol between the NFC tag106and the authentication server102, the authentication application401re-launches the third party application403using the callback URL. When the third party application403attempts to access the protected resource, the third party server430queries the authentication server102. The outfacing authentication server410provides the authentication result to the third party server430. The third party server430, on confirming that the user device104and/or third party application403is authenticated, permits the third party application403to access one or more protected resources.

As discussed above, embodiments may provide for key rotation. Key rotation allows for the updating or replacement of existing keys and/or provisioning new keys to the NFC tag106. After a successful challenge/response authentication protocol, the authentication server102may send one or more new keys to the NFC tag106. The new keys may replace old or existing keys stored in a memory of the NFC tag106. Keys stored on the NFC tag106may be rotated periodically to protect against attack. In some embodiments, keys on the NFC tag106may be replaced after each or after a certain number of authentications are performed. In other embodiments, keys stored on the NFC tag may be updated after a certain elapsed time regardless of the number of authentications performed with one or more old keys. The authentication server102will typically initiate the key rotation procedure although in some instances another device such as NFC tag106may initiate the key rotation procedure. In embodiments with multiple key servers, the key rotation intervals may be different for each key server.

In some embodiments, secret rotation may be utilized. NFC tags may have protected storage. For example, the MIFARE DESFire™ EV1 token provides for protected storage therein. Read and write commands on a given NFC tag such as NFC tag106may be protected and require a special key or other authorization. As, discussed above, a session key may be established after a successful completion of a challenge/response protocol. By way of example, in the authentication processes ofFIGS. 2 and 3, RndA and RndB may be utilized to derive a session key used for future read/write operations to protected storage on NFC tag106.

In some embodiments, a successful completion of a challenge/response authentication protocol depends on the establishment of a shared secret. For example, in the authentication processes ofFIGS. 2 and 3, the NFC tag106and authentication server102may establish a shared secret after authenticating one another. The NFC tag106can store the shared secret in a protected storage, while the authentication server102can store a hash of the shared secret in a memory of the authentication server102. To authenticate the user device104, the NFC tag106can send a message to the user device104for forwarding to the authentication server102which comprises the shared secret encrypted with a session key. As discussed above, a session key may be derived from RndA and RndB. The authentication server102, on receiving the message from the user device104, can decrypt the message to obtain the shared secret. If a hash of the obtained shared secret matches the hash of the shared secret stored in a memory of the authentication device102, the user device104is authenticated.

In embodiments where multiple key servers are used, each key server may compare a calculated hash of a received shared secret with the hash of the shared secret stored in a memory of the authentication server to authenticate a user device. For example, key server A412may receive a first value which is encrypted using the session key and calculate a hash of the first value. If the calculated hash of the first value matches the hash of the shared secret stored in the memory of the authentication server102, the key server A412authenticates the user device104. The key server B414may receive a second value which is encrypted using the session key and calculate a hash of the second value. If the calculated hash of the second value matches the hash of the shared secret stored in the memory of the authentication server102, the key server B414authenticates the user device104. By storing a hash of the shared secret in a memory of the authentication server102rather than the shared secret itself, the authentication server102is protected from attacks. The shared secret stored in a protected storage of the NFC tag106and the hash of the shared secret stored in a memory of the authentication server102may be rotated or updated periodically in a manner similar to the described above with respect to the key rotation process.

FIG. 5shows one possible implementation of the communication system100ofFIG. 1.FIG. 5shows the authentication server102and user device104connected over a network501. The user device104is also connected to NFC tag106using an NFC connection. The user device104is an example of a processing or computing device. A processing device may comprise, for example, a computer, a smartphone or other mobile telephone, a tablet, or other type of communication device.

Authentication server102comprises a processor521coupled to a memory523and a network interface525. The processor521may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements. The memory523may comprise random access memory (RAM), read-only memory (ROM) or other types of memory, in any combination.

The memory523and other memories disclosed herein may be viewed as examples of what are more generally referred to as “computer program products” storing executable computer program code.

Also included in the authentication server102is network interface525. The network interface525allows the authentication server102to communicate over the network501with the user device104, and may comprise one or more conventional transceivers.

The user device104comprises processor541coupled to memory543. The processor541may comprise a microprocessor, a microcontroller, an ASIC, an FPGA or other type of processing circuitry, as well as portions or combinations of such circuitry elements, and the memory543may comprise RAM, ROM or other types of memory, in any combination.

Also included in the user device104is network interface545. The network interface circuitry545permits the user devices104to communicate over the network501with the authentication server102and other user devices, servers, etc. not shown inFIG. 5. The network interface circuitry545may comprise one or more conventional transceivers.

The user device104further comprises NFC interface547. The NFC tag106similarly comprises an NFC interface567, permitting the user device104and the NFC tag106to establish an NFC connection.

The NFC tag106further comprises a processor561coupled to a memory563. The processor561may comprise a microprocessor, a microcontroller, an ASIC, an FPGA or other type of processing circuitry, as well as portions or combinations of such circuitry elements, and the memory563may comprise RAM, ROM or other types of memory, in any combination. The NFC tag106may be implemented as a lightweight processing device with limited processing power. The NFC tag106may be configured to draw its power from the NFC field established in the NFC connection with the user device104.

The network501may comprise, for example, a global computer network such as the Internet, a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network such as WiFi or WiMAX, or various portions or combinations of these and other types of networks.

The NFC tag106, as described above, may take on a number of form factors. In addition, the NFC tag106may be embedded within another device such as user device104. The NFC tag106may be associated with a particular user device such as user device104. The NFC tag106may alternatively be used with a number of distinct user devices. In some embodiments, the NFC tag106may be located within a physical casing of the user device104, though the NFC tag106may be removable.

The NFC tag106may comprise an authentication token such as the RSA SecurID® user authentication token, commercially available from RSA, The Security Division of EMC Corporation, of Bedford, Mass., U.S.A., suitably modified to function as described herein. Authentication tokens may be time-synchronous tokens, event synchronous tokens, hybrid time-synchronous and event synchronous tokens, or various other token types. An authentication token may be a hardware authentication token or a software authentication token.

It is to be appreciated that the particular set of elements shown inFIG. 5is presented by way of example, and in other embodiments additional or alternative elements may be used. Thus, another embodiment may include additional networks and additional sets of user devices, servers and NFC tags.

As mentioned previously, various elements of the communication system100such as user devices, authentication servers, NFC tags or their associated functional modules may be implemented at least in part in the form of software. Such software is stored and executed utilizing respective memory and processor elements of at least one processing device. The system may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other types of processing devices.

Such processing platforms may include cloud infrastructure comprising virtual machines (VMs) and one or more associated hypervisors. An example of a commercially available hypervisor platform that may be used to implement portions of the communication system100is the VMware® vSphere™ which may have an associated virtual infrastructure management system such as the VMware® vCenter™. The underlying physical machines may comprise one or more distributed processing platforms that include storage products, such as VNX and Symmetrix VMAX, both commercially available from EMC Corporation of Hopkinton, Mass. A variety of other storage products may be utilized to implement at least a portion of the system.

The particular processing operations and other system functionality described in conjunction withFIGS. 1-4are presented by way of illustrative example only, and should not be construed as limiting the scope of the invention in any way. Alternative embodiments can use other types of processing operations for authentication. For example, the ordering of the process steps may be varied in other embodiments, or certain steps may be performed concurrently with one another rather than serially.

The foregoing examples are intended to illustrate aspects of certain embodiments of the present invention and should not be viewed as limiting in any way. Other embodiments can be configured that utilize different authentication techniques.

It is to be appreciated that the authentication and other processing functionality such as that described in conjunction withFIGS. 1-4and the associated examples above can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as a computer or server. As mentioned previously, a memory or other storage device having such program code embodied therein is an example of what is more generally referred to herein as a “computer program product.”

Also, the particular configuration, elements and operating parameters of the embodiments described above are not requirements of the invention, and should not be construed as limiting the scope of the invention in any way. For example, whileFIGS. 2 and 3show particular examples of a challenge/response authentication protocol without and with device binding, respectively, numerous variations of challenge/response authentications and device or other identity binding techniques may be utilized. In addition, other authentication protocols may be used in addition to or in place of the specific challenge/response authentication protocols described herein. Examples of conventional authentication protocols are disclosed in A. J. Menezes et al., Handbook of Applied Cryptography, CRC Press, 1997, which is incorporated by reference herein. These conventional processes, being well known to those skilled in the art, will not be described in further detail herein, although embodiments of the present invention may incorporate aspects of such processes.

As another example, in the authentication processes described above, various devices may initiate the challenge/response authentication protocol. In addition, the respective devices which act as an NFC initiator and an NFC target may vary. In some embodiments, the user device104may act as the NFC initiator in establishing an NFC connection with the NFC tag106. In other embodiments, the NFC tag106may act as the NFC initiator.

Moreover, the various simplifying assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the invention. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.