Dual card programming for access control system

A method of programming an access control system including presenting an access card and a configuration card to a device; determining a validity of the access card at the device; process the configuration card at the device; decrypting a payload on the configuration card based on information from the access card; using the payload form the configuration card to switch the device to a high security mode of operation.

BACKGROUND

The present disclosure relates generally to access control systems, and more particularly, to a system and a method of programming an access control.

An access control system is typically operated by encoding data on a physical key card that indicates access rights. Some access control systems are online where the access control reader that reads key cards can use some means to communicate with the access control system. In online systems the access rights are usually a reference identifier. An example is a building entry system where an employee uses a RFID badge to access a door that has a reader with means to convey the badge id into a networked access control system that has means to permit or deny access based on access rights associated to the reference identifier and additionally based upon the time and date allowed for access. In this example, the reader does not have means to determine the time and date, but the access control system does. Other access control systems are offline and the access rights are encoded as data that can be decoded and interpreted by the offline access control lock to retrieve the access rights. An example is a hotel locking system where a front desk encodes a guest card and an offline, battery powered lock on a guest room door has the means to decode the key card and permit or deny access based on the encoded access rights and based on the time and date allowed for access. In this example, the door lock has means to determine time and date. Some methods of encoding access rights include sequencing where subsequent access rights have a sequence number that is greater than the prior access rights. Some other methods of encoding access rights include an expiration window where the access rights will not provide access before a certain date and time or after another certain date and time.

Conventional access control systems utilize encryption, i.e., AES, RSA, ECC, etc., to perform cryptographic operations to authenticate communications with physical cards or virtual cards passed over Near Field Communications (NFC) or Bluetooth. Additionally, encryption is also used to encode data on the key card where the access rights may be encoded as encrypted data or as a digital certificate which may also be encrypted. Sometimes the keys used for authenticating cards are different than the encryption keys used to encode data on the cards. Locks and readers and encoders require these various encryption keys to be programmed before entry into service or are occasionally changed as part of normal encryption key management. Management of these encryption keys requires a programming device and programming operation to program the encryption keys that are specific to the access control system being put into service. A conventional method of setting keys in a reader or lock is to use a programming device. Another conventional method is to use a single configuration card that has the new keys on the card rather than access rights. The card can be read by an online reader, but since the reader does not have a real time clock, it cannot expire the configuration card even if an expiration window is encoded on the card. In some cases, a reader that is part of a lock may not be able to expire the configuration card either as the reader is a module that doesn't have means to get the time and date from the lock. Because the configuration card may not expire, it needs to be carefully controlled. Another conventional cryptographic operation, is to preload the specific encryption keys in the factory and pre-configure the lock for the property before being put into service, however this creates an operational process that can be cumbersome for a factory to manage.

High security RFID systems are available to replace older, less secure technologies. For example, MIFARE Plus uses high security AES 128-bit encryption keys and is an upgrade from MIFARE Classic which uses 48-bit keys for a proprietary encryption algorithm. However locks and readers can be made that support both MIFARE Plus and MIFARE Classic. In some cases there is a need to switch the reader into a high security only mode and optionally to set the high security encryption keys.

It would be advantageous to be able to operate high-security locks with legacy software systems to minimize the operational impact of upgrading the entire system all at once. Additionally, it would be advantageous to have a secure process for upgrading or rolling keys that uses a card and is not dependent on a programmer or special device or required to be pre-configured in a factory. Additionally, it would be advantageous to have a configuration card that expires for all types of devices.

SUMMARY

A method of programming an access control system, the method according to one disclosed non-limiting embodiment of the present disclosure can include presenting an access card and a configuration card to a device; determining a validity of the access card at the device; processing the configuration card at the device in response to the validity of the access card; decrypting a payload on the configuration card based on information from the access card; and using the payload from the configuration card to switch the device to a high security mode of operation.

A further embodiment of the present disclosure may include, wherein switching to a high security mode of operation could be to change any programmable parameter in the access control device.

A further embodiment of the present disclosure may include, using encryption keys from the payload on the configuration card for use with a device that is a door lock.

A further embodiment of the present disclosure may include, using encryption keys from the payload on the configuration card for use with a device that is an encoder.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card and the configuration card as high security cards.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card as a low security card and the configuration card as high security card.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting at least one of the access card and the configuration card via a mobile device.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card and the configuration card via a mobile device.

A further embodiment of the present disclosure may include, wherein switching the device to a high security mode of operation is a software based front desk system that is upgrading an old system and keys are being transferred from the old system to a new software system.

A further embodiment of the present disclosure may include, wherein processing the configuration card at the device in response to the validity of the access card is not processing the configuration card if the access card is expired.

A method of programming an access control system, the method according to one disclosed non-limiting embodiment of the present disclosure can include encoding a first card as an access card and a second card as a configuration card; presenting the access card and the configuration card to a device; determining a validity of the access card at the device; processing the configuration card at the device in response to the validity of the access card; decrypting a payload on the configuration card based on information from the access card; and using the payload form the configuration card to switch the device to a high security mode of operation.

A further embodiment of the present disclosure may include, wherein information from the access card is used to create a diversified encryption key by an encryption process that incorporates multiple information inputs and produces an encryption key that is related to all of the inputs which is then used to encrypt the contents of the configuration card.

A further embodiment of the present disclosure may include, using encryption keys from the payload on the configuration card for use with an access control device.

A further embodiment of the present disclosure may include, using encryption keys from the payload on the configuration card for use with a device that is a door lock.

A further embodiment of the present disclosure may include, using encryption keys from the payload on the configuration card for use with a device that is an encoder.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card and the configuration card as high security cards.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card as a low security card and the configuration card as high security card.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting at least one of the access card and the configuration card via a mobile device.

A further embodiment of the present disclosure may include, wherein presenting the access card and the configuration card includes presenting the access card and the configuration card via a mobile device.

A further embodiment of the present disclosure may include, providing an indication of completion in response to the switch of the device to the high security mode of operation.

A further embodiment of the present disclosure may include, presenting the access card and the configuration card simultaneously.

A further embodiment of the present disclosure may include, wherein processing the configuration card at the device in response to the validity of the access card is not processing the configuration card if the access card is expired.

A system for programming an access control according to one disclosed non-limiting embodiment of the present disclosure can include an encoder to encode an access card and a configuration card that program the access control when presented together to the access control.

A further embodiment of the present disclosure may include, wherein the access card and the configuration card are presented simultaneously.

A further embodiment of the present disclosure may include, wherein the access card and the configuration card are presented in sequence.

A further embodiment of the present disclosure may include, wherein the configuration card is not processed if the access card is expired.

DETAILED DESCRIPTION

FIG. 1schematically illustrates an access control system10. The system10generally includes a mobile device12, a server14, and a plurality of access controls16, schematically illustrated as16a,16b, . . . ,16nalong with a front desk interface28which communicates with an encoder300to encode guest cards204and/or communicates with a programmer21to program the access controls16a,16b, . . . ,16n. In one embodiment, the front desk interface28is integrated with the programmer21to provide for an integrated platform. In another embodiment, the front desk interface28is integrated with the encoder300to provide for a portable check-in experience where an administrator can roam in a lobby area checking guests into rooms. It should be appreciated that, although particular systems are separately defined in the schematic block diagrams, each or any of the systems may be otherwise combined or separated via hardware and/or software.

The mobile device12may be a wireless capable handheld device such as a smart phone that is operable to communicate with the server14and the access controls16. The server14may provide credentials and other data to the mobile device12, such as firmware or software updates to be communicated to one or more of the access controls16. Although the server14is depicted herein as a single device, it should be appreciated that the server14may alternatively be embodied as a multiplicity of systems, from which the mobile device12receives credentials and other data.

Each access control16is a wireless-capable, restricted-access, or restricted-use device such as wireless access control16, access control readers for building entry, electronic banking controls, data transfer devices, key dispenser devices, tool dispensing devices, and other restricted-use machines. The mobile device12submits credentials to the access controls16, thereby selectively permitting a user to access or activate functions of the access controls16. A user may, for example, submit a credential to an electromechanical lock to unlock it, and thereby gain access to a restricted area. In another example, a user may submit a credential to an electronic banking control to withdraw funds. In still another example, the user may submit the credential to a unit that dispenses key cards with data associated with or data retrieved from the credential. A mobile device12may store credentials for one or all or other of the examples noted above, and in addition may store a plurality of credentials for each type of application at the same time. Some credentials may be used for multiple access controls16. For example, a plurality of electronic access control16in a facility may respond to the same credential. Other credentials may be specific to a single access control16.

With reference toFIG. 2, a block diagram of an access control16agenerally includes a lock actuator22, a lock controller24, a lock antenna26, a lock transceiver28, a lock processor30, a lock memory32, a lock power supply34, a lock card reader90and a credential module36. The lock card reader90may include a card reading subsystem91, a communication subsystem93, to communicate with the lock processor30, a feedback subsystem95such as a light, buzzer, etc. The lock card reader90reads physical cards and then sends the data to the lock processor30for decoding and determining if the access device16may be accessed. Alternatively, the reader90could be included in an embodiment as a lock for a door16a, or in a reader16bon a building where the door is controlled by a door controller component separate from the access control16bwith the reader90and where the communication subsystem93is used by the reader16bto communicate with the networked access control system. Alternatively, the reader90or lock processor30could have means to determine date and time.

The access control16ais responsive to credentials from a physical card and/or the mobile device12. Upon receiving and authenticating an appropriate credential from the mobile device12using the credential module36, or after receiving card data from lock card reader90, the lock controller24commands the lock actuator22to lock or unlock a mechanical or electronic lock. The lock controller24and the lock actuator22may be parts of a single electronic or electromechanical lock unit, or may be components sold or installed separately.

The lock transceiver28is capable of transmitting and receiving data to and from at least the mobile device12. The lock transceiver28may, for instance, be a near field communication (NFC), Bluetooth, or Wi-Fi transceiver, or another appropriate wireless transceiver. The lock antenna26is any antenna appropriate to the lock transceiver28. The lock processor30and lock memory32are, respectively, data processing, and storage devices. The lock processor30may, for instance, be a microprocessor that can process instructions to validate card data and determine the access rights contained in the card data or to pass messages from a transceiver to a credential module36and to receive a response indication back from the credential module36with card data. The lock memory32may be RAM, EEPROM, or other storage medium where the lock processor30can read and write data including but not limited to lock configuration options and the lock audit trail. The lock audit trail may be a unified audit trail that includes events initiated by accessing the lock via the lock card reader90or the mobile device12. The lock power supply34is a power source such as line power connection, a power scavenging system, or a battery that powers the lock controller24. In other embodiments, the lock power supply34may only power the lock controller24, with the lock actuator22powered primarily or entirely by another source, such as user work (e.g. turning a bolt).

The credential module36is in communication with the lock processor30and is operable to decrypt and validate a credential to extract virtual card data communicated into the lock controller24as a “virtual card read.” That is, the access control16ahas essentially two readers, one reader90to read a physical key card and the credential module36to communicate with the mobile device12via the lock processor30and the transceiver28and antenna26.

While theFIG. 2shows the lock antenna26and the transceiver28connected to the processor30, this is not to limit other embodiments that may have additional antenna26and transceiver28connected to the credential module36directly. The credential module36may contain a transceiver28and antenna26as part of the credential module. Or the credential module36may have a transceiver28and antenna26separately from the processor30which also has a separate transceiver28and antenna26of the same type or different. In some embodiments, the processor30may route communication received via transceiver28to the credential module36. In other embodiments the credential module may communicate directly to the mobile device12through the transceiver28.

With reference toFIG. 3, a method200of programming encryption keys and possibly other configuration data into high-security card readers is generally illustrated in a simplified block diagram format. The method follows the method of changing the encoder behavior when encoding an access card when two cards are detected in the RFID field (FIG. 7). One card is an access card204such as a Hotel Master card, guest card, or other, such card while the other card is a configuration card202(FIG. 4). The difference between the two cards is the semantics of the payload on the card and how the payload is encrypted on the card.

After encoding, with reference again toFIG. 3, when presenting the two cards simultaneously to an access control16(step210), the access control16detects the two cards and will process the door access card204first (step220). On success it then decrypts the configuration card202(step230) and then uses the configuration card202payload to configure the access control16(step240), for example, to roll to new keys, to change operating modes, or set any other configurable parameter that is typically set in the access control16. In an embodiment where the access control16is a wall reader in an online access control system, processing the door access card204(again, step220) would include first reading the access rights from the card (encoded as a reference identifier), passing the access rights to the networked access control system, and receiving back at the access control16an indication that the access control system accepted the card. The indication from the access control system could be a message, or a signal line that indicates the reader16should give positive feedback (i.e. Green LED or positive beep tones, etc.) or negative feedback (i.e. Red LED or negative beep tones, etc.). Further, in this embodiment, the step230would then only proceed if the positive indicator was given. An alternate embodiment is where the access control16is a hotel door lock with components as shown inFIG. 2as part of an offline access control system. In this embodiment, processing the door access card204(step220) could be the same as the previous embodiment where the reader90is like the wall reader with means to pass the encoded access rights data to the processor30which gives an indication back to the reader of success. A successful indication would mean that the access rights were accepted and not expired. Again, in this embodiment, the step230would then only proceed where the reader90then decrypts the configuration card payload and in step240the reader90processes the card payload if the access rights were accepted and not expired. In this embodiment the reader90securely stores the encryption keys for reading cards and the keys are not exposed to the lock processor30. Yet another embodiment is where the reader90passes all data and steps230and240are done by the lock processor30and in this embodiment the lock processor securely stores the encryption keys and configures the reader90with the keys so the reader can read cards. Yet another embodiment is where the reader90and lock processor30are combined. Yet another embodiment is where the reader90gets the date and time from the lock processor30so that the reader90can determine if a configuration card is expired.

The configuration card202may be securely encrypted with a diversified key based upon information from the access card204so that the two cards are tied together. Thus, when the access card204expires, the configuration card202also effectively expires. Additionally, configuration card202can be used only on the access control16that the access card204is authorized to open. Finally, when finished, if the two cards are separated or one of the cards is reprogrammed or destroyed, then the configuration card202becomes unusable and thus the information contained on it is secure.

With reference toFIG. 5, an encoder300can write to door access cards204and the access control16can read the cards to determine if guests, housekeepers, or other staff can gain access. Here, access control16is in ‘classic’ mode in which the readers90thereof are backwards-compatible in operation with older, less secure cards and technologies such as MIFARE Classic, for example. In this mode the encoder (HT22p) will only encode MIFARE Classic cards with room card data to be door access cards204. The access control16in classic mode will only read MIFARE Classic cards and process the room card data. In this mode, if a high security card is presented to the lock, the reading will fail with feedback95such as a red light or with a buzzer sound that indicates failure of the operation. This mode is offered for compatibility to existing installations and legacy systems.

With reference toFIGS. 6 and 7, when a system is desired to upgrade to high security mode, the dual card encoding method400may be performed as follows:

The encoder is prepared to encode (write) an access card (step402). The user may select a menu option on the encoder or via controlling PMS (Property Management System) software, Font Desk Software28, etc. The method of instructing the encoder to encode a card is well known.

The user then presents two cards (step404). For example, one card can be a lower security card, one can be a higher security card: e.g., a MIFARE Classic card and a MIFARE Plus card together simultaneously. Alternatively, first a MIFARE Classic card and immediately thereafter present a MIFARE Plus card subsequently within a short time. Alternatively, if two lower security cards are presented together or in sequence—encode the first as a door access card204but reject the second and not encode a configuration card. Alternatively, if two higher security cards are presented together or in sequence—encode the first as a high-security door access card204and encode the second as a configuration card202to be used to re-configure and roll or change the encryption keys in access control16that are already in high-security mode. Alternatively, if no high-security encryption keys are present in the encoder, randomly generate new high-security encryption keys when two cards are presented to the encoder.

Next, encode the first card as the door access card204(step406). If one card is low security and one is high security, the low security card should be encoded as the door access card204. This provides so that an access control16in low security mode can read this access card and then switch to the higher security mode using the method200(FIG. 3).

Next, encode the second (higher security) card as the configuration card202(step408). The encoded data contains configuration information to change the access control16from low security mode to high security mode, including, but not limited to, the high-security encryption keys. The configuration data is encrypted with a process using information from the first door access card204, including but not limited to, a unique card ID, payload data from the access card, etc., so that the two cards are tied together and must be used together. A different door access card204would have a different unique card ID or different payload data and thus that different access card could not be used in conjunction with this configuration card202.

Alternatively, with reference toFIG. 9, information from the door access card204is used to create a diversified encryption key by a hash or encryption process that incorporates multiple information inputs and produces an encryption key that is related to all of the inputs (FIG. 7, step410). These key diversification algorithms are well known in the art of cryptography, for example NXP has published an application note for key diversification (http://www.nxp.com/documents/application_note/AN10922.pdf). This diversified encryption key is then used to encrypt the contents of the configuration card202.

The user then presents the two cards together to another device that can read the cards and the device reads the cards in sequence or together (step420). This step may be the same as method200described inFIG. 3where the device is an access control16. Both cards are identified and read to determine the type of card and information contained on the card (e.g. whether this is a door access card204a configuration card202or both and which is which).

For a door lock type device16, the access card is processed first. If the access card is valid: a) Authorized for this device, and b) Not expired, then the lock will process the configuration card by decrypting the payload based on information from the access card and then use the configuration data to switch to a high security mode of operation with the specified encryption keys.

Alternatively, if the device in step420is another encoder300that is instructed to read a card, it will detect the two cards in the field and after reading them, will retrieve the encryption keys from the configuration data on the configuration card and save the encryption keys for later use in encoding high-security door access cards204and (optionally) switch to a high security mode. Alternatively, the encoder can use a ‘mode’ where it would not program a high-security card until it was configured to be in high-security mode (FIG. 8).

If the device in step420is an access control16and is a door lock (e.g. for a hotel room door) then it will enter a high-security mode after processing the configuration card. This means the door lock would no longer accept low-security cards. So, if after switching modes, the same low-security door access card was presented to the lock, it would no longer be read but would be rejected with e.g. a red light.

If the access control16was already in high-security mode and the two cards presented were both high-security cards, the card with access data would be processed first and then the configuration card would be processed. In this case, the lock is already in high-security mode and so would not change modes. The configuration data could change some other operating parameter in the access control16. For example, the configuration data could include new high-security encryption keys and the lock would roll or change its encryption keys to these new ones. The rolling or changing of encryption keys could happen immediately. Optionally, to minimize disruption to an actively used access control system, the new encryption keys could be stored in the access control16and access cards204could be encoded using the old keys (if an encoder was not upgraded yet) or new keys (if it was upgraded) and the access control16could use either old or new keys for some amount of time until the old keys would expire. Or, optionally, the encoder would provide an indication in the access card204that the old keys should no longer be used and the lock would then delete the old keys. Or, optionally, the lock only stores the new keys and the encoder would put both access rights encoded using the old keys and access rights encoded using the new keys on the access card204. In this case, locks that had not yet rolled to new keys would use the access rights encoded with old keys and locks that had rolled would use the access rights encoded with new keys. The encoder could then only put access rights encoded using the new keys on cards after all the locks had been rolled.

On a successful configuration step, the device (lock16or encoder300) could indicate feedback to the user via Audio, or LED light sequence, etc. that the operation was completed (step430). In one example, a distinctive indication may be utilized so that the user can differentiate normal operations from a successful (or failed) configuration operation.

An alternate embodiment of the method is where the encoder300has a menu option to encode a configuration card or the front desk software28that controls the encoder has a menu option. The encoder would 1) cache the previously encoded access card204or 2) could read an access card204and then follow steps408-410above to create the associated configuration card. Or, another option is to 3) provide menu options to re-encode a specified access card and then would follow all steps402-410above in sequence with both cards. One benefit of this alternate embodiment is so that the creation of configuration cards could be controlled based on user permissions in the encoder300or front desk software28.

Another alternate embodiment is where the encoder300is a software application running locally at the hotel or in the cloud and communicating with an encoding device that can encode physical cards. This would apply to either the case where the application and encoder are performing steps402-408, or encoding access cards204, or configuration cards202. Or this could apply to the case in step420, for example, where an older system is being upgraded to a new software based system that needs to retrieve the old keys from the old encoders. By reading the access card and configuration card encoded by old encoders, the new software-based system is operable to securely receive the keys and can then participate in the hotel system without requiring a new encryption key to be programmed into all the access controls16.

With reference toFIG. 8, the system is now operating in Plus Mode or High Security mode. The encoder will encode MIFARE Classic OR MIFARE Plus cards, but doors will only accept MIFARE Plus cards.

With reference toFIG. 10, an encoder perspective of the method described above begins with 1) a Factory mode where it is compatible with ‘classic’ devices and cards. Then, after 2) using the method400above, it switches to 3) a Plus mode where it only encodes high security cards (unless the configuration method400above is used again and in that case it creates a classic access card for the sole purpose of upgrading a lock that is still in factory mode, for example a replacement lock from the factory for another lock that failed). Then, the method400above can be used again to 4) Roll keys in the property so that it can still operate in a 5) Plus mode with new keys.

With reference toFIG. 11, a lock perspective of the method described above begins with 1) Factory mode where the lock only reads low security cards but can be switched to a high security mode using 2) The methods200and400above. In 3) Plus mode, the lock then would reject a classic/low-security card and only read high-security cards. But, it could also read a high-security access card and configuration card to 4) Roll the keys to a different set of high-security keys and then 5) Operate in a high security mode with new keys.

Another embodiment is to utilize a mobile device12(FIG. 1) as either the access card or configuration card or both. When used as one of the cards, the mobile device12would be presented to the encoder300(FIGS. 5, 6, 8) along with another card. The encoder300writes using the standard RFID protocols to the card or to the mobile device. The mobile device12would emulate a card to the encoder and the encoder would not know that the mobile device12is not a card. Then, the mobile device12could be presented with the card to the lock to complete the two card presentation. Again, the lock would not know that the mobile device12is not a card. In the case when the mobile device12is both cards, it would present itself as first one card and then as a second card, presenting two different card types and UIDs to the encoder300. The mobile device12would use the sequence embodiment of the method where the cards are presented in rapid sequence. The mobile device12would then present both cards in sequence to the access device16to affect the method of programming.

Optionally, the card data on the mobile device12could be over the air downloaded from a remote service and the mobile device could present the card data as two cards to the encoder300to change the encoder into a high security mode and then be presented as two cards to a lock16ato change the lock into a high security mode.

Optionally, the mobile device12could be encoded with an access card by an encoder with the mobile device12in card emulation (this is part of the NFC standard), and then the mobile device12could utilize the access card along with over the air downloaded information to create a configuration card on the mobile device that could be presented as the second card. Optionally, the access card data could be uploaded to a service that then creates the configuration card based on the access card and downloads the configuration card to the mobile device so that the encryption keys and process of creating the configuration card is done by a secure service and not exposed on the mobile device. The mobile device12could then present the two cards together in sequence as emulated cards to be read by an encoder300or access device16.

Yet another additional embodiment is where the encoder300and the mobile device12are combined into a single device. An administrator would program the access device16using the mobile device12which would simulate an access card204and a configuration card202using card emulation mode (again, part of NFC) when presented to the access device16.