USING IDENTITY CREDENTIALS AS A KEY FOR SECURELY CONTROLLING A LOCK CONNECTED TO A WIRELESS NETWORK

Locks may rely upon identity credentials to act as keys for unlocking and/or locking the locks, such as door locks. The identity credentials may be digital credentials that hold identity information and evidence of knowledge of secret information, such as a password or a private cryptographic key. The door locks in exemplary embodiments may be connected to an access system via wireless network, such as a low power low frequency Wi-Fi network, like a HaLow network. The wireless network enables the door locks to communicate with the access system, such as a server for a lodging establishment. The access system may receive identity credentials and forward the identity credentials to an authentication service for authentication. The access system may also pass the identity of the guest to an authorization service to determine if the guest is authorized to unlock the door lock or not.

BACKGROUND

Lodging establishments, such as hotels and motels, formerly provided guests with metal keys. Unfortunately, such metal keys were susceptible to being lost, stolen, or not returned to the lodging establishments. Such metal keys that were lost, stolen, or not returned had to be replaced at the lodging establishments' expense. In addition, the lost, stolen, and not returned keys posed a security risk in that such metal keys could still be used to gain access to guest rooms. Some lodging establishments would replace their locks periodically at great expense to reduce the risk of misuse of such lost, stolen, and not returned metal keys.

Due to these drawbacks of metal keys, plastic programmable keys have been widely adopted by lodging establishments. The plastic programmable keys have a magnetic strip or a radio-frequency identification (RFID) tag that encodes information that may be read by a door lock to unlock the door. The encoded information typically includes a room number and a start time and an end time for which the key is valid. In some instances, the encoded information includes a guest number as well.

There are also drawbacks to programmable plastic keys. Such plastic programmable keys are lost frequently and require replacement. The cost of replacing such plastic programmable keys over time may be substantial for lodging establishments. In addition, the plastic programmable keys may pose a security risk. Any party that is in possession of a plastic programmable key who knows what room is associated with the plastic programmable key may gain access to the room with the key. Thus, stolen, lost, and not returned keys may be problematic if they fall into the wrong hands.

SUMMARY

In accordance with a first aspect, a method may be performed by a processor of a computing device. The method may include receiving, from a door lock and over a wireless network, a secure package comprising a cryptographic payload, the cryptographic payload generated by a contactless card based at least in part on a cryptographic key for the contactless card. The method may further include transmitting the cryptographic payload to an authentication service for authentication based at least in part on an instance of the cryptographic key for the contactless card maintained by the authentication service. The method may further comprise receiving a response from the authentication service indicating that the cryptographic payload was authenticated based at least in part on the instance of the cryptographic key for the contactless card maintained by the authentication service. The method may further comprise determining, based on access information, that a user associated with the contactless card is authorized to unlock the door, and sending a communication over the wireless network to the door lock to cause the door lock to unlock.

The cryptographic payload may be encrypted. The door lock may be for a door of a guest quarters in a lodging establishment. The authentication service may be located remotely at a different street address from the door lock. The authentication service may be a cloud service. The wireless network may be a Wi-Fi® network.

In accordance with another aspect, a method may be performed by a processor of a mobile computing device. In the method, the processor may wirelessly connect with a door lock. A message may be generated that includes a cryptographic payload for a user that wishes to unlock the door lock and the generated message may be wirelessly sent to the door lock to unlock the door.

The wirelessly connecting with the door lock may include using near field communication (NFC) to wirelessly communicate with the door lock. The mobile computing device may be one of a smartphone, a smartwatch, a tablet computer, or another type of wearable computing device. The cryptographic payload may be encrypted. The cryptographic payload may include a one-time password. The cryptographic payload may be received from a contactless card.

In accordance with an additional aspect, method may be performed by processing logic of a door lock that is connected to a wireless network. The method may include receiving, from a contactless card, a secure package comprising a cryptographic payload, the cryptographic payload generated based at least in part on a cryptographic key for the contactless card. The method may further include transmitting, via a wireless network, the cryptographic payload to an authentication service for authentication based at least in part on an instance of the cryptographic key for the contactless card maintained by the authentication service. The method may further include receiving a response from the authentication service indicating that the cryptographic payload was authenticated based at least in part on the instance of the cryptographic key for the contactless card maintained by the authentication service. The method may further include sending a communication to an authorization service to determine whether a user associated with the contactless card is authorized to unlock the door lock, and receiving, from the authorization service, an indication specifying that the user associated with the contactless card is authorized to unlock the door lock. The method may further include unlocking the door lock based on the responses received from the authentication service and the authorization service.

DETAILED DESCRIPTION

The exemplary embodiments may provide door locks and/or other locks that rely upon identity credentials to act as keys for unlocking and/or locking the locks. The identity credentials may be digital credentials that hold identity information and evidence of knowledge of secret information, such as a password or a private cryptographic key. The use of the identity credentials may enhance security by requiring possession of a touchless card, a private cryptographic key or other confidential information that is presumed to be known only by the party associated with a given identity. Parties other than the identified party may not possess such identity credentials and thus may not be able to use the key. This approach reduces the risk associated with conventional keys at lodging establishments where an unauthorized party may use the key to gain access to a guest's room.

The exemplary embodiments may not require a physical key. Thus, there is no physical key that may be lost or stolen. As such, lodging establishments may not need to continually replace physical keys at substantial expense. The identity credentials may be kept in or may be generated using a mobile computing device, such as a smartphone, smartwatch, a tablet computing device, a laptop computer, or the like. Moreover, such mobile computing devices may require a user to enter a username and password to gain access to software installed thereon. As such, the identity credentials may be more secure than conventional plastic programmable keys.

The locks in exemplary embodiments, such as door locks, may be connected to an access system via wireless network, such as a low power low frequency Wi-Fi network, such as a HaLow® network. The wireless network may enable the door locks to communicate with the access system, such as server for a lodging establishment. A HaLow network may facilitate direct connections between the door locks and the access systems. A HaLow network may directly connect the door locks and the access system separated by over 1 kilometer in distance. The use of a HaLow network may eliminate the need for a traditional Wi-Fi network to route the signal. As such, one may place the access system a kilometer away or may place the access system in a basement which may not need any other networking components. The use of the HaLow network may be especially beneficial for hotels. The HaLow network may enable the access system to be placed in storage buildings or other buildings that don't have existing Wi-Fi infrastructure.

As such, hotel clerks may unlock doors from their computer terminal rather than needing to be at the door to use a key. The access system may receive identity credentials and forward the identity credentials to an authentication service for authentication. The access system may also pass the identity of the guest to an authorization service to determine if the guest may be authorized to unlock the door lock or not. More generally, access control information may be stored for the guest by the authorization service where the access control information determines what areas the guest has access to, like a guest room, spa, fitness center, etc.

FIG.1depicts an illustrative computing environment100that may be suitable for exemplary embodiments. The computing environment100may include a mobile computing device102that may interact with a door lock104. As will be discussed in more detail below, the mobile computing device102and the door lock104may wirelessly communicate with each other as indicated by the dotted line interconnecting the mobile computing device102and the door lock104. The door lock104may be connected to a wireless network106, such as a HaLow network (e.g., an Institute of Electrical and Electronics Engineers (IEEE) 802.11ah network). HaLow networks may require low power and may operate at low frequencies that may enable good penetration through walls and other structures relative to other wireless networks. In addition, HaLow networks may have good range relative to other wireless networks. Hence, HaLow networks may be good candidates for use in the embodiments described herein. Moreover, the HaLow networks may have the benefit that access systems may be positioned where there is no Wi-Fi infrastructure and may be positioned remotely from hotel rooms over one kilometer away.

An access system110may be connected to the wireless network106and may communicate with door lock104and other door locks105via the wireless network. The access system may be realized as a computing device, such as a server computer, that regulates access to the guest rooms via the door locks104and105. Software for controlling the door locks may be stored and run on the access system110. The access system110may be connected to one or more authentication services112and114. The authentication services112and114may run on server computer systems, local computing devices, or a cloud services infrastructure. The access system110may connect with the authentication services over a network connection, such as over the Internet. The authentication services112and114may authenticate identity credentials of a user to authenticate the identity of the user and may be realized in software, hardware, or a combination thereof. The authentication services112and114may, in some exemplary embodiments, authenticate identity credentials originating at least in part from a touchless (or contactless) card, such as the Presto card from Capital One Financial Corporation. The authentication services112and114may in some exemplary embodiments authenticate identity credentials that may be provided via the Fast IDentity Online (FIDO®) Alliance FIDO2 authentication protocol, or from any another cryptographic identity authentication protocol.

The access system110may have a connection to access an authorization service116. The connection may be a network connection, such as via a local rea network (LAN), a wide area network (WAN), or a combination thereof. The authorization service116may be realized in software running on a computing device. The authorization service116may receive requests for whether a party is authorized to interact with a door lock104, such as whether the party is authorized to unlock the door lock104or not. The authorization service116may look up information in a database to determine whether the party is authorized or not authorized. For each guest, the database may hold, for example, information regarding what room the guest is in, what dates and times the guest has access to the room, and/or access control rights for the guest. The authorization service116may return the information from the database118to the access system110or may return an answer whether the guest is permitted to unlock the door lock or not permitted to unlock the door lock. Based on the information provided by the authentication services112and114and/or the authorization service116, the access system110may decide whether to permit a user to unlock a door lock or not. As discussed below, the access system110may send messages, commands, or signals to the door lock104to unlock the door lock104.

Although the discussion herein includes unlocking a door lock, because most door locks for lodging establishments default to a locked state when closed, it should be appreciated that the authorization may also be to lock a door lock or to both lock and unlock a door lock. The door lock may be for a guest room or may be for other portions of a lodging establishment, such as a fitness center, a business center, a pool, or the like. The lock may also be in an elevator to limit access to particular floors, such as floors that are part of a concierge level.

Moreover, the lock need not be a door lock in a lodging establishment but may be a door lock in other settings, such as in an office building, an office, a storage facility, a military base, a hospital, a prison, etc. Still further, the lock may not be a door lock, but rather may more generally be a lock that limits access to a space, enclosure, item, etc.

FIG.2Adepicts an example mobile computing device200that may be used by a user, such as a guest of a lodging establishment, to unlock a door lock for a guest room (or other doors, items, or areas in the lodging establishment). The mobile computing device200includes a processor202. The processor202may be, for example, a microprocessor like a central processing unit (CPU) or a graphics processing unit (GPU), a logic circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a microcontroller. The processor202may have access to a storage204. The storage204may include both primary memory and secondary memory. The storage204may include random access memory (RAM), read only memory (ROM), optical storage, magnetic storage, removable storage media, solid state memory or the like. The storage204may include non-transitory computer-readable storage media. The storage204may include computer programming instructions, such as a card application206. The card application206provides support for use of a contactless card, such as a smart card, like the Presto card from Capital One Financial Corporation. The storage204may also include a web browser207for browsing the Worldwide Web. The storage204additionally may include identity credentials208for the user. The storage204may hold a key application210that contains instructions for enabling the mobile computing device200to be used as a key that may wirelessly present a digital key to the door lock104.

The mobile computing device200may include NFC circuitry for making the mobile computing device200NFC-capable. The NFC circuitry212may include, for example, an antenna, a wireless adapter, and a wireless transceiver. The mobile computing device200may include a display214, such as a touchscreen display, a light-emitting diode (LED) display, or a liquid-crystal display (LCD), for displaying text, graphical content, or video content. The mobile computing device200may include input devices216, like a touchscreen, depressible buttons, a thumbwheel, keys, a thumb pad, a mouse, etc. The mobile computing device200may include a network adapter218for interfacing with a network. The mobile computing device200may include a modem220, such as a cellular modem.

The mobile computing device200may take many different forms, such as depicted inFIG.2B. The mobile computing device200may be a smartphone230or a smartwatch232. The mobile computing device200may be a laptop computing device238or a tablet computer234. The mobile computing device200may be a wearable device236. The depicted examples of types of mobile computing devices are intended to be illustrative and not limiting.

FIG.3depicts components of an illustrative door lock300that may be suitable for exemplary embodiments. The door lock300may include processing logic302. The processing logic302may include a microprocessor, an FPGA, an ASIC, electrical circuitry, or the like for controlling operation of the door lock300. The door lock may include storage304, such as non-transitory computer-readable storage media, e.g., random access memory (RAM), read-only memory (ROM), solid state memory, optical storage media, magnetic storage media, or the like. The storage304may include primary memory and/or secondary memory as well as caches. The storage304may store computer programming code that may be executable by the processing logic302to control operation of the door lock300. The door lock300may include a wireless network adapter308enabling the door lock300to connect to the wireless network106. The door lock300may include an internal calendar311and a clock310for maintaining the current date and time. The door lock300may include a locking mechanism312, such as a bolt that can move between a lock and an unlocked position, and an actuator314for actuating the locking mechanism312. The actuator314may be a motor or other electrically driven actuator. The door lock300may include a housing313for encasing the internal components of the door lock300. The housing313may be designed to be integrated with a door, and the locking mechanism312may be designed to interact with features, such as a striker plate on a door jamb of a door frame for the door. The door lock300may include NFC circuitry316for enabling the door lock300to communicate with other entities via an NFC wireless protocol.

FIG.4depicts illustrative components of the access system400suitable for exemplary embodiments. The access system400may include a processor402, such as a microprocessor, like a CPU or GPU, a FPGA, an ASIC, or other variety of processor. The access system400may include a storage404. The storage404may include primary memory and/or secondary memory and may include non-transitory computer-readable media, like RAM, ROM, solid state memory, magnetic storage media, optical storage media or the like. The storage404may store computer programming code406, which may be executed by the processor402to perform operations of the access system400as described herein, such as obtaining authentication from the authentication services112and114, obtaining authorization from the authorization service116, receiving communications from the door locks104and105, sending communications to the door locks104and105, and generally controlling the door locks104and105. The access system400may include a display, such as a touchscreen, an LED display, an LCD display, or the like. The access system400may include input devices410, such as a touchscreen, a mouse, a keyboard, a thumbpad, a microphone, etc. The access system400may include a wireless adapter412for connecting with the wireless network106and a network adapter414for connecting with a wired network, such as a LAN, like an Ethernet network, or the like. The access system400may have Internet access via its wired network connection.

FIG.5depicts a flowchart500of illustrative steps that may be performed in exemplary embodiments to unlock a lock, such as a door lock. These same operations may more generally apply to unlocking all types of locks in alternative embodiments. Initially, at502, a user may input identity credentials to the mobile computing device102, such as by receiving the credentials from a contactless card or typing in the credentials. Different ways of inputting the identity credentials will be detailed below. At504, the user may interact with a lock, such as door lock104, using the mobile computing device102. This may entail approaching the door lock104and initiating a wireless NFC session between the mobile computing device102and the door lock104. A communication between the mobile computing device102and the door lock104may take place to pass the identity credentials from the mobile computing device102to the door lock104. At505, the identity credentials may be forwarded to the access system110via the wireless network106. At506, the access system110may send the identity credentials to one of the authentication services112and114to authenticate the identity credentials as authentic. At508, the authentication services112or114may return a response indicating, to the access system110, whether the identity credentials have been deemed authentic or not authentic. If the credentials are not authentic, at510, the door lock may remain locked. No further action may be taken, or the user may be informed that the attempt to unlock the door lock104has failed by receiving feedback via the mobile computing device102from the access system110or by receiving feedback from the door lock104, such as a red light on the door lock illuminating. In other embodiments, no such notification may be sent.

Where the authentication indicates that the identity credentials are authenticated, at514, a check may be made whether the user is authorized to unlock the door lock104. This may entail the access system110sending the identity information to the authorization service116and receiving a response. At514, a check may be made to determine whether the user is authorized. If the user is not authorized, at510, the door may remain locked. A notification may, in some embodiments, be sent from the access system110to the user via the mobile computing device102or the door lock104indicating that the user is not authorized. In other embodiments, no notification may be sent. Where the user is authorized, the door lock104may be unlocked at516by the access system110sending a message, command, or signal to the door lock104that causes the actuator314to actuate the locking mechanism312to the unlocked position under the control of the processing logic302.

As mentioned above, the identity credentials may be input to the mobile computing device102in different manners.FIG.6Adepicts a flowchart600which may depict steps that may be performed when the identity credentials are input by way of a contactless card. This flowchart will be described relative toFIG.6B. Initially, at602, the key application210may be executing on the processor202of the mobile computing device200. At604, the key application210may prompt the user to tap the contactless card632to the mobile computing device636(or otherwise bring the card632within communications range of device636) to initiate an NFC session between the contactless card632and the mobile computing device636. Doing so may cause the contactless card632to transfer identity credentials in a secure package634to the mobile computing device636. The key application210may invoke the card application206to interact with the contactless card632. When the contactless card632is placed in sufficient proximity with the mobile computing device636, an NFC session is established.

As part of the NFC session, at606, the contactless card632may generate the secure package634that may hold the identity credentials.FIG.7Adepicts one example of how the secure package634may be generated. The generation of the secure package634may employ cryptographic hash functions, such as MD5 or SHA-1.FIG.7Ashows a block diagram700depicting how the cryptographic hash functions may be used in exemplary embodiments. In the example shown inFIG.7A, three inputs702,704and706may be passed through a hash function710together. The choice of depicting three inputs is intended to be illustrative and not limiting. Other numbers of inputs may be used in some instances. The hash function710may produce an output hash value712. Due to the nature of the hash function710, it may be computationally difficult to derive the inputs702,704and706from the hash value712without knowing the key708used by the hash function608. The key708may therefore only be stored or otherwise accessible by the contactless card632and the authentication service112.

The key708may be dynamically generated for each session and may be particular to the contactless card632. In some embodiments, the key708is generated based on an encryption key stored by the contactless card (e.g., the key814), where a copy of the key is maintained by the authentication service112. In some embodiments, the key708is dynamically generated for each session by encrypting the key maintained by the card and a counter value maintained by the contactless card to generate a dynamic key708. The dynamic key708may then be used for the hash function608. Thus, the hash function710may provide a layer of security for the content (e.g., inputs702,704and706) that may be included in the secure package634.

In the exemplary embodiments, the inputs702,704and706may vary depending on the information the parties agree to exchange and/or the agreed protocol for authenticating the initiating party.FIG.7B, shows a diagram720of possible types of inputs722that may be hashed in exemplary embodiments. The inputs722may be agreed upon by the contactless card632and the authentication service112. In these exemplary embodiments, a one-time password724generated by the contactless card632may be included as an input. An account identifier726for the initiating party may be provided as an input. This may be an account number or other identifier that uniquely identifies the account of the initiating party. As was described above, the account identifier726may be a phone number for the initiating party. The inputs722may include a counter value728maintained by the contactless card632. In some embodiments, the counter value728is synchronized with the authorization service116and/or the authentication services112,114. The inputs722may include a name730of the initiating party. As an added layer of security, the hash value712may be encrypted in some embodiments.

With reference again toFIG.6, at608, the contactless card632may send the secure package634to the mobile computing device636. The mobile computing device636may receive the secure package at610. As shown inFIG.6B, the secure package634may then ultimately be included in a message638that may be sent from the mobile computing device636to the access system over the wireless network (see step506inFIG.5). The access system may then provide the message638to the authentication service112for authentication. To verify authenticate the hash value712generated by the contactless card, the authentication service112may recreate the hash value712using the agreed-upon inputs722. The authentication service112may then compare the recreated hash value712to the hash value in the secure package634(which may be decrypted if encrypted). If the comparison results in a match, the authentication service112authenticates the secure package634and transmits an indication of the authentication to the access system110and/or the authorization service116. If the comparison does not result in a match, the authentication service112does not authenticate the secure package634and transmits an indication of the failed authentication to the access system110and/or the authorization service116. Doing so may cause the access system110and/or the authorization service116to reject a requested unlocking of a door lock or any other lock.

FIG.8Aillustrates an exemplary contactless card800that may be used in exemplary embodiments. The contactless card800may be a payment card, such as a credit card, a debit card, or a gift card, issued by a service provider805displayed on the front or back of the card800. In some exemplary embodiments, the contactless card800is not related to a payment card, and may comprise, without limitation, an identification card. In some instances, the payment card may comprise a dual interface contactless payment card. The contactless card800may comprise a substrate820, which may include a single layer or 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 card800may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card800may otherwise be compliant with the ISO/IEC 14443 standard. However, it is understood that the contactless card800according 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 card800may also include identification information815displayed on the front and/or back of the card, and a contact pad810. The contact pad810may be configured to establish communications with another communication device, such as a user device, smart phone, laptop, desktop, or tablet computer. The contactless card800may also include processing circuitry, antenna and other components not shown inFIG.8A. These components may be located behind the contact pad810or elsewhere on the substrate820. The contactless card800may also include a magnetic strip or tape, which may be located on the back of the card (not shown inFIG.8A).

As illustrated inFIG.8B, the contact pad810ofFIG.8Amay include processing circuitry825for storing and processing information, including a microprocessor830and a memory835. It is understood that the processing circuitry825may contain additional components, including processors, memories, error and parity (e.g., cyclic redundancy check (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 memory835may be configured to store one or more applets840, a master key814, a diversified key826, one or more counters845, and a customer identifier850. Generally, a server (such as the authentication service112) and the contactless card800may be provisioned with the same master key814(also referred to as a master symmetric key). More specifically, each contactless card800is programmed with a distinct master key814that has a corresponding pair maintained by the server. For example, when a contactless card800is manufactured, a unique master key814may be programmed into the memory838of the contactless card800. Similarly, the unique master key814may be stored by the server (e.g., in a hardware security module).

Furthermore, when a given card800is manufactured, a diversified key826may be diversified from the master key814via function that takes, as input, a diversification factor and the master key814. In some embodiments, the diversification factor may be the counter845of the contactless card800. The diversified key826may be stored in the contactless card800and the server. The master key814and diversified key826may be kept secret from all parties other than the contactless card800and server, thereby enhancing security. Furthermore, as described below, the value of the counter845may change over time. As such, the diversified key826may change as well.

The one or more applets840may comprise one or more software applications configured to execute on one or more contactless cards, such as Java Card applet. However, it is understood that applets840are not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory. The one or more counters845may comprise a numeric counter sufficient to store an integer. The counters845may correspond to the counter728ofFIG.7B. The counters845may be synchronized with a server, such as the authorization service116and/or the authentication services112,114. Each time a read operation takes place, the counter845may be configured to increment. In some examples, each time data from the contactless card is read (e.g., by a mobile device), the counter845is transmitted to the server for validation and determines whether the counter845is equal to an instance of the counter845maintained by the server (and/or are within a threshold amount). Therefore, when data is received from the card, the server may increment the instance of the counter845maintained by the server. As another example, when the mobile device reads data from the contactless card, the mobile device may inform the server of the read, which may cause the server to increment the instance of the counter845maintained by the server.

In some embodiments, the counter845may be included in a cryptographic payload generated by the contactless card800and included in cleartext with the cryptographic package. The cryptographic payload may comprise a one-time password (OTP). In such embodiments, the server may recreate the diversified key826based on an instance of the master key814and an instance of the counter845maintained by the server. The server may then decrypt the cryptographic payload using the diversified key826, which may produce the counter value. The server may then compare the decrypted counter value845with the unencrypted counter845to validate or authenticate the cryptographic payload.

The customer identifier850may comprise a unique alphanumeric identifier assigned to a user of the contactless card800, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier850may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account.

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 pad810or entirely separate from it, or as further elements in addition to processor830and memory835elements located within the contact pad810.

In some examples, the contactless card800may comprise one or more antennas855. The one or more antennas855may be placed within the contactless card800and around the processing circuitry825of the contact pad810. For example, the one or more antennas855may be integral with the processing circuitry825and the one or more antennas855may be used with an external booster coil. As another example, the one or more antennas855may be external to the contact pad810and the processing circuitry825.

In an embodiment, the coil of contactless card800may act as the secondary of an air core transformer. The terminal may communicate with the contactless card800by cutting power or amplitude modulation. The contactless card800may 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 card800may 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.

As explained above, the contactless card800may be built on a software platform operable on smart cards or other devices having limited memory, such as JavaCard, and one or more applications or applets may be securely executed. Applets may be added to contactless cards to provide an 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, and produce an NFC Data Exchange Format (NDEF) message that comprises a cryptographically secure OTP encoded as an NDEF text tag. One example of an NDEF OTP is an NDEF short-record layout (SR=1). In such an example, the one or more applets840may be configured to encode the OTP as an NDEF type4well known type text tag. In some examples, NDEF messages may comprise one or more records.

FIG.8Cdepicts a flowchart860of steps that may be performed by the authentication service112when a contactless card800is used. Initially, at862the authentication service112may use decryption keys to decrypt the secure package634. As stated, the authentication service112may recreate the decryption keys to decrypt the secure package, e.g., by encrypting the master key814and the counter value845to generate the diversified key826. In addition, the decryption keys may be used to decrypt the hash value712to extract the inputs that were hashed together by the hash function710. In some embodiments, the authentication service112recreates the hash value using the same inputs used by the contactless card and compares the recreated hash value to the decrypted hash value to verify the hash value. At864, the extracted password724and counter value728may be compared with a valid password and a valid counter value (e.g., valid passwords and counter values stored by the authentication service112in a database). At866, a determination may be made whether the passwords match and the counter values match or if the extracted counter value otherwise indicates that the password has not expired. For example, if the extracted counter value does not equal (or is not within a threshold value) of the valid counter values, the authentication service112may determine the password has expired. At868, if the passwords match and the extracted password has not expired based on the extracted counter value, other extracted information may be compared. At872, if the other information is valid based on the comparison, then, at874, the user's identity may be authenticated, and a success message may be returned to the access system110. If not, at870, the user's identity is not authenticated, and a failure message may be sent to the access system110. Similarly, at870, if the passwords do not match or the password has expired as indicated by the extracted counter value, the initiating party is not authenticated, and a failure message may be sent.

The identity credentials may also be provided using a cryptographic key.FIG.9depicts a flowchart900depicting illustrative steps that may be performed in exemplary embodiments when such an approach to providing identity credentials is used. Initially, at901, the user may register with the authentication service112or114, such as a FIDO2 authentication service. This may include providing a name, email address, and choosing a password. Other personal information may also be provided. Once registered, the user may be provided with a private cryptographic key from the authentication service112or114. The registration may be completed as a separate transaction before the user seeks to open the door lock104. When the user wishes to unlock the door lock, at902the user may access a web page using web browser207or invokes the key application210on the mobile computing device, where the user is prompted to enter an email address and password. If the correct email address and password are provided, at904a cryptographic challenge may be presented that seeks a response. The correct response may require access to the private cryptographic key. At906, the user may generate the response using the private key and send the response to the authentication service112or114.

FIG.10depicts a flowchart1000showing illustrative steps that may be performed in authenticating the user with a crypto challenge by the authentication service112or114. At1002, the authentication service112or114may receive the email address and password from the user as described above. At1004, the authentication service112or114may determine whether the email address is for a registered user and may determine that the received password matches a registered password for the user. If the email address is not for a registered user or the password does not match the registered password, at1006a message may be sent to the mobile computing device102of the user indicating that at least one of a wrong email address or password was provided and the authentication may cease. If the proper email address and password were provided, at1008the authentication service112or114may issue a cryptographic challenge that requires the user to be in possession of the private key that was issued to use upon registration. A number of different cryptographic challenge approaches may be adopted, such as that used with the FIDO2 authentication protocol. At1010, a response may be received at the authentication service112or114from the mobile computing device102of the user. At1012, the authentication service determines whether the response was correct. At1014, if the response is correct, a success message may be sent. If the response is not correct, at1016a failure message may be sent.

FIG.11Adepicts a flowchart1100showing illustrative steps that may be performed by the authorization service116in processing a user request to unlock a lock, such as a door lock. At1102, the authorization service116, may receive the user's identity (e.g., name) and the room number of the guest room. At1104, the database118may be accessed to determine for information regarding the guest. The database118may hold a list of all current guests, what room numbers they may access and over what dates and times they may access the room(s). In addition, the database118may hold access rights for the guest that may be used to determine what locks the guest may unlock. Based upon what is in the database118, at1106, a response may be generated by the authorization service116and sent to the access system110. The response may contain the information for the guest that was retrieved from the database118in some embodiments or may indicate an absence of information in the database for the guest. Alternatively, the authorization service116may process the data to determine whether the user is authorized or not to unlock the lock, such as the door lock104for the specified guest room. In some embodiments, the access system110processes the data to determine whether the user may unlock a door.

FIG.11Bdepicts a flowchart1120showing illustrative steps that may be performed by the access system110or the authorization service116to determine whether the user is authorized to unlock the lock, such as door lock104, based on information retrieved from the database118. At1122, a determination may be made as to whether the user is a registered guest. If the user is not a registered guest, at1128, the user may be deemed to be not authorized. If the user is registered as a guest, at1124, a determination may be made as to whether the user possesses access rights to unlock the specified lock. If the user does not have access rights, at1128, the user may be deemed to be not authorized. If the user has access rights, at1126, a date/time check may be made to determine if the user is currently authorized to unlock the lock. If the user is currently authorized, the user may be deemed to be authorized to unlock the lock, and an unlock instruction may be sent to the lock. If the user is not authorized, at1128, the unlock instruction may not be sent to the lock.

While the present disclosure has been described with reference to exemplary embodiments herein, it will be appreciated that various changes in scope and detail may be made without departing from the intended scope as defined in the appended claims.