METHODS AND APPARATUS OF ASSIGNING PRIVILEGED USERS TO ACCESS CONTROL SYSTEMS

Abstract

Aspects of securely assigning new authorized users to networked equipment for the purposes of gaining entry into that equipment or accessing valuable data from that equipment are addressed. High security access key fobs are assigned to individual users and serve as proxies for their identities. A new user creation fob or other secure two-factor authentication method is used to verify the identity of a newly enrolled or newly modified user.

Claims

1. A system comprising a networked central database, an electronic safe, and an electronic user fob: the networked central database storing safe users and associated unique identification numbers; the electronic safe controlled by an electronic safe controller; an electronic fob reader for reading electronic user fobs, wherein the electronic safe is at least in occasional communication with the networked central database by way of a network connection, a list of allowed safe users and corresponding access rights are exchanged from the networked central database to the safe, the controller authenticates safe users for the purpose of granting access to secure data stored within the controller, door access, or both; the electronic user fob contains at least the user's unique identification number, and wherein, a multi-factor authentication method is required at the safe to accept the electronic user fob on the first access attempt by that fob at that safe, a first factor authentication being presentation of the electronic user fob at the electronic safe; and the user is authenticated with the electronic user fob alone on subsequent electronic safe access.

2. The system of claim 1 where the multi-factor authentication method includes the presentation of a temporary code.

3. The system of claim 1 where the multi-factor authentication method includes the presentation of a recognized electronic fob having a similar or higher privilege level as the electronic user fob.

4. The system of claim 1 wherein the electronic fob has a uniquely programmed and unalterable identification number (fob id) which is employed as the user's unique identification number.

5. The system of claim 4 wherein the fob id is a unique media access control number having at least 48 bits.

6. The system of claim 1 wherein when user permissions for to electronic fob are to be increased, an authentication fob is presented to and recognized by the electronic safe to confirm the increased permissions for a first time.

7. The system of claim 6 where upon subsequent presentation of the electronic fob, the increased permissions are available.

8. A system comprising a networked central database, an electronic safe, an electronic user fob, and an authentication fob: the networked central database storing electronic safe users and associated unique identification numbers; the electronic safe controlled by an electronic safe controller and having an electronic fob reader for reading electronic user fobs; the electronic safe communicating at least occasionally with the central networked database by way of a network connection, wherein a list of allowed safe users and corresponding access rights are exchanged from the networked central database through the network to the electronic safe; the controller authenticates safe users for the purpose of granting access to secure data stored within the controller, door access, or both; the electronic user fob contains at least the user's unique identification number; an authentication fob is used to expedite the authentication of new electronic user fobs by requiring presentation of the authentication fob at the safe to accept the electronic user fob on the first access attempt by that fob at that safe, and the user may authenticate with the electronic user fob alone on subsequent safe access.

9. A system comprising a networked central database, an electronic safe, and an electronic user fob: the networked central database stores safe users and associated unique identification numbers; the electronic safe is controlled by an electronic safe controller, and has an electronic fob reader for reading electronic user fobs; the electronic safe is at least in occasional communication with the networked central database by way of a network, whereby a list of allowed safe users and corresponding access rights are exchanged from the networked central database over the network to the safe, the controller authenticates safe users for the purpose of granting access to secure data stored within the controller, door access, or both; and the electronic user fob stores at least the user's unique identification number, wherein, a multi-factor authentication method is required at the safe to accept the electronic user fob if the permissions of that user have been modified since the fob was last used at that safe, and the user may authenticate with the electronic user fob alone on subsequent safe accesses.

10. The system of claim 9 further comprising: a programming terminal having registration software and a fob programmer utilized to program electronic user fobs and authentication fobs.

11. The system of claim 10 wherein the programming terminal writes an encrypted password into the electronic fob.

12. The system of claim 11 wherein the encrypted password is derived form a unique fob identification number and a shared secret shared with the electronic safe.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] FIG. 1 illustrates a networked system of electronic smart safes which communicate with a central server to implement methods and apparatus of assigning privileged users in accordance with a first embodiment of the present invention;

[0030] FIG. 2 illustrates a first process of user registration in accordance with a first embodiment of the present invention;

[0031] FIG. 3 illustrates a process of preprogramming a fob and storing the data at the server of FIG. 1 which is preferably used in conjunction with the first process of user registration of FIG. 2;

[0032] FIG. 4 shows a flowchart illustrating an exemplary user experience at an electronic smart safe in accordance with the present invention;

[0033] FIG. 5 illustrates a process of adjusting user permissions in accordance with the first embodiment of the present invention;

[0034] FIG. 6 illustrates a process of full user registration at the safe in accordance with a second embodiment of the present invention;

[0035] FIG. 7 illustrates a process of user interaction at an electronic smart safe where the second registration process of FIG. 6 is completed utilizing a user fob of higher privilege to complete the first-time registration process;

[0036] FIG. 8 illustrates a process of user interaction at an electronic smart safe where the registration process of FIG. 6 is completed with an authentication fob;

[0037] FIG. 9 illustrates a process of user interaction at an electronic smart safe where the registration process of FIG. 6 is completed with a temporary code;

[0038] FIG. 10 illustrates presently preferred control electronics for an electronic smart safe supporting user registration in accordance with both embodiments of the present invention; and

[0039] FIG. 11 illustrates an interaction between the safe, server, administrator and user during the registration process in accordance with the first embodiment of the present invention.

DETAILED DESCRIPTION

[0040] The present invention presents a secure method and apparatus for adding users to one or more networked pieces of security equipment that are centrally administered. In the context of this disclosure, the security equipment described is in the form of a smart safe, but the disclosure should be understood as equally applicable to other types of security equipment such as electronic storage lockers or the like. FIG. 1 shows a networked system 100 having a plurality of electronic smart safes 110.sub.1 . . . 110.sub.N (collectively 110) each containing a respective safe controller 115.sub.1 . . . 115.sub.N networked utilizing network 120 with a central server database 152. An administrator access point 150 permits viewing and modifying data from the database 152 which stores data such as lists of security equipment 156, such as fobs, authentication fobs, electronic smart safes and the like; lists of authorized equipment users 158 including their roles or in other words the equipment that they are authorized to interact with and the nature of that interaction; as well as user records 159 as addressed further below. A plurality of user fobs 180.sub.1 . . . 180.sub.N (collectively 180) are utilized as part of a two-part registration process as discussed further below in connections with a discussion of FIGS. 2-5, 10 and 11 or a full registration at the safe and a one-part process of a second embodiment as discussed in conjunction with FIGS. 6-10.

[0041] System 100 also preferably includes a programming terminal 160 with keyboard 166. The programming terminal includes registration software 162 for programming fobs and a fob programmer 164. Terminal 160 is utilized by the system administrator in programming fobs 180 and authenticator fobs 190. While one authenticator fob 190 is shown for ease of illustration, it will be recognized that in a typical system more than one authenticator fob will be employed though the number will be significantly less than the number of fobs 180. The programming terminal 160 could also serve as an administrator access point 150.

[0042] In the first embodiment, a two-part registration process 200 shown in FIG. 2 is employed. In a first step 202, a central administrator logs into a secure database, such as secure database 152 of FIG. 1 utilizing access point 150 of FIG. 1, for example. The database 152 contains records of all security equipment 156 and equipment users 158 including their roles or permissions. New users are assigned an electronic key fob or fobs, such as one or more of the fobs 180. Preferably, each user is assigned a single key fob. Electronic fobs can take the form of a wireless fob, for instance, using Bluetooth low energy (BLE), near field communication (NFC), WiFi, Zigbee, Optical link, or various other standard RF communications protocols. The wireless fob can take the form of a smart phone, tablet, beacon, or device that houses an appropriate transceiver. Other possible electronic key fobs take the form of a conductive path style fob such as a Maxim Semiconductor iButton™ fob, a USB based key fob, or the like.

[0043] Each electronic fob is provided to the administrator with a uniquely programmed and unalterable identification (fob ID) number 182 which advantageously is employed as a proxy for the user name. The fobs also have a unique preprogrammed password 184 which is preferably encrypted, such that a private key and decryption algorithm or cryptographic hash function is necessary to validate the plaintext password. Because the user ID number and passwords are only ever machine exchanged, there is no need for either to be easy to remember. Thus, the password 184 can be as long and strong as desired. In accordance with a presently preferred embodiment of the invention, the plaintext password is preferably a random 128-bit number and is preferably derived from the fob ID number and a shared secret in the form of a private key shared between the electronic safe and the programming terminal 160. The fob ID number is preferably the 48-bit unique BLE media access control (MAC) address or the 48-bit unique identifier code found in all iButton™ chips.

[0044] In step 204, the administrator associates a fob, such as one of the fobs 180, with its described preprogrammed fob ID number to a particular equipment user in a process of preregistration 300 further illustrated in FIG. 3.

[0045] A preregistration process 300 in accordance with one presently preferred embodiment proceeds as follows.

[0046] First, in step 302, the administrator connects the electronic fob to a programming and registration terminal, such as terminal 160 of FIG. 1 which employs the registration software 162 and fob reader 164 as follows.

[0047] In step 304, the registration software copies the fob's id number which may also be referred to as its username.

[0048] In step 306, the registration software also writes the encrypted password into the electronic fob. Preferably, the encrypted password is derived from the user id and a cryptographic shared secret between the fob and the equipment for which the fob is to be used with.

[0049] In step 308, the administrator optionally uses registration software to write on the fob any non-access control related user metadata 186, such as employee name, employee ID number, a truck number of a truck to be utilized by the employee, a route number, employee email address, employee cellular phone number and the like.

[0050] In step 309, the administrator assigns permissions to the user record including access rights and restrictions for a piece of networked security equipment or a group of networked pieces of security equipment.

[0051] In step 310, the registration software stores the username and metadata into the networked server as a user record 158a.

[0052] In step 312, the administrator removes the electronic fob from the terminal and assigns it to the assigned user.

[0053] An advantage to deriving the programmed encrypted password from the fob ID number and a cryptographic shared secret in step 306 is that there is no need to store the encrypted password on the networked server in step 310. If the encrypted password is not derived deterministically from the ID number, this encrypted password would also need to be stored on the server and synchronized with the safe equipment.

[0054] Returning to FIG. 2, in step 205, the user record data is exchanged with the safe or group of safes which the administrator has assigned the user access. Any safe that receives a user record will preregister that user in the safe.

[0055] After preregistration is completed, the user can take the newly assigned access fob to any of the safes to which the user was assigned by the administrator in step 309. At each safe, in step 206, the user completes the registration process performing the following tasks:

[0056] in step 208, the user connects the electronic fob to the safe or otherwise uses the fob to communicate with the safe;

[0057] in step 210, the safe recognizes the fob as a pre-registered user, but identifies this use as the first time at the safe;

[0058] in step 212, the safe prompts the user for authentication following one of the below 2FA methods:

[0059] in step 214A, the user presents a specially issued authentication fob given to the user to expedite full registration;

[0060] alternatively, in step 214B, the user presents a fully registered electronic fob of a similar or higher permissioned user of the same equipment; or

[0061] in step 214C, the user enters a secure temporary code, such as an OTC, for example.

[0062] In step 216, upon recognition of one of the above valid credentials, the new user fob is fully registered by the safe.

[0063] In step 218, the safe communicates the full registration details inclusive of the 2FA method used (along with the previously registered user ID from step 214B if applicable) to the networked database 152.

[0064] Two-part registration in the manner of process 200 eliminates the potential of a hacker successfully adding new safe users on the networked server to be later exploited to gain access. It also provides a quick and secure method of fully authorizing the new user on each piece of equipment without adding too much time and tediousness to that first visit to each newly registered safe.

[0065] FIG. 4 illustrates the ease of the first visit while summarizing the process 400 of user interactions on the first and subsequent visits to the electronic smart safe in the first embodiment of the invention. In step 402, the user presents a fob to the safe. For example, the user clicks a button, such as button 181 on the fob 180 causing the fob to communicate using BLE transmission which is received by the safe. The registration status of the fob is evaluated by the safe in step 404. If the fob is not recognized as either status (1) fully registered with unmodified permissions or as status (2) belonging to a preregistered new user or to a registered user with modified permissions, then access is denied in step 406. If the registration state is determined to be status (1) in step 404, then the user is granted access to conduct authorized activity at the safe in step 408. One example of such activity is for a CIT employee to open the safe with the fob and remove any stored valuables, such as cash from the safe. Another example is for an authorized service person to open the safe to perform service thereon.

[0066] If in step 404, the status was determined to be status (2), then in step 410, the user is prompted to provide the second factor of two factor authentication (2FA) as discussed above in connection with steps 212, 214A, 214B, 214C and 216 of process 200. In step 412, if a valid 2FA credential is presented, then in step 414, the user is now fully registered and can conduct authorized activity in step 408.

[0067] If in step 412, it is determined the 2FA credential was not valid, access is denied in step 406.

[0068] The authentication fob, such as fob 190 utilized in step 214A of process 200, is intended to be protected by the company responsible for the servicing of the safes, typically a CIT company. Thus, authentication fobs will typically only be made available to new staff that are visiting safes for the first time and upon completion of those visits will be retrieved from them. The authentication fob can take the form of an RF fob or conductive path fob. Authentication fobs are typically registered to a collection of deployed equipment ahead of time. When one is presented to such a safe, the safe is prompted to accept a new user credential or the credential of a user is modified as discussed above in connection with FIG. 2 or below in connection with FIGS. 6 and 8. Preferably, when a valid authentication fob is presented to the safe, the safe will allow for the creation of one particular type of user with predetermined access control privileges. For example, presenting an authentication fob results in the association of any following key fob with privileges of a CIT user. Authenticator fobs alternatively may restrict new users to a subset of available permission levels to prevent for example, a CIT user creating or assigning a new service person credential.

[0069] It should be noted that for newly installed equipment, all safe users assigned to the safe can be fully registered in advance so the above process is only necessary when new users are added to existing equipment. Preferably, when adding a user list to a brand new safe or a new safe controller that is replacing an existing safe controller, an alternate method can be used that bypasses the need to have a second factor authentication while still maintaining the system's security. One such method is to set a new controller configuration software flag (1049 in FIGS. 1 and 10) in the safe controller at the factory before it ships inside a new safe or to be used as a replacement controller for an existing safe. On power up, the safe controller will see the new controller configuration flag is set which will permit the reception of a user list from the server and will immediately fully register all users received. The new controller configuration flag will be cleared after the user list is sent down that first time. Alternative methods of clearing the new controller configuration flag could be after a set period of time from power up as measured by the system clock, by a privileged safe user such as the service person or installer of the safe once user list is confirmed, an administrator after the safe has been placed into service, or after a certain number of transactions occur at the safe. Once the new controller configuration flag is cleared, any further updates to the user list from the server will only appear as partially registered and will require the described 2FA methods to fully register those new or modified users.

[0070] Temporary codes preferably take the form of OTCs. These OTCs can be generated by a central administrator in response to a randomly generated challenge code displayed at the safe. This central administrator function can be either automated by a program that provides the challenge code response or can be manually implemented, for example, in response to a conversation with an individual that has access to the response code generation tool. Temporary codes may also take the form of a code of the day which may suitably be implemented with a coordinated shared secret lookup table that advances both on the safe and is synchronized with a central administrator tool such that access codes for a particular safe on a particular day can be generated in advance of a trip. Temporary codes may suitably be exchanged between the administrator and the safe user either by phone call, web software tool, a printed report generated in advance, or some other secure manual or automated exchange mechanism.

[0071] Referring now to FIG. 5, if an administrator wishes to change the permissions of a user for one or more safes, he or she can do so without needing the user's electronic fob utilizing process 500 in the following manner.

[0072] In step 502, the administrator accesses the secure networked database 152 via an access point 150 with proper network credentials.

[0073] In step 504, the administrator adjusts the permissions of a user. Examples include changing privileges of the user at a particular safe or group of safes or changing the safes for which the user has access.

[0074] In step 505, the server communicates any user record modifications to the safes impacted.

[0075] In step 506, after the changes are made by the administrator, when the user goes to a safe where his privileges are modified to allow increased access, the safe requires additional authentication through one of the previously covered three 2FA methods at the safe. If the user's privileges are decreased or eliminated, preferably no 2FA method is necessary and the safe reduces or eliminates access privileges accordingly. In instances where increased control over any user record changes are desired, the same 2FA method can be imposed.

[0076] In step 508, once a new user is fully registered or after a user is validated to have increased permissions, the 2FA requirement for that user is removed to allow for expedient future credential validation. This removal of the 2FA requirement for one user does not however preclude the use of 2FA methods involving a second individual presenting their credentials to perform security-sensitive activities which will often be the case.

[0077] In a process 600 in accordance with a second embodiment of the invention shown in FIG. 6, a user is added at the networked safe locally, without pre-registration from a central administrator. The steps for complete registration at the safe in this method 600 and the user experience in this second embodiment are detailed in FIGS. 6-9 as follows.

[0078] In process 600 of full registration at the safe, in step 601, the user is prompted for authentication.

[0079] The user to be newly added is authenticated using one of three procedures of authentication 602A, 602B or 602C (collectively 602). According to procedure 602A, log in is made with a role or permissions greater than those to be added. For example, the new user's supervisor may log in with a higher permission fob or loan that fob to the new user for the day when the new user is making a first visit to a safe or safes.

[0080] According to procedure 602B, log in is authenticated with a temporary code.

[0081] According to procedure 602C, log in is authenticated with an authenticator fob.

[0082] In step 604, the new user selects from a safe menu the option to add a new user at the safe with a particular role, such as collecting cash or performing maintenance. This list of available roles is restricted based on permission level of partner user in method 602A, the permission level associated with the OTC method 602B, or based on configuration of authentication fob used in method 602C.

[0083] In step 606, the new user presents the fob at the safe.

[0084] In step 608, the safe reads the fob's user identification and encrypted password.

[0085] In step 610, the encrypted password is verified based on user identification and shared secrets between the safe and the programming terminal 160.

[0086] In step 612, the user adds any metadata to associate with the recognized fob and the safe saves it as a user record.

[0087] In step 614, the safe transmits a new user record to the networked database 152 along with the 2FA authorized method used (and with the previously registered user ID from step 602A if applicable).

[0088] Upon successful transmission of the new user record, the registration process is complete in step 616 and the new user fob is fully registered and may be used at the safe in the future as discussed further in connection with FIGS. 7-9.

[0089] Step 610 above assumes the preferred previously discussed fob password was derived from the user ID and shared secrets between the safe and the programming terminal 160. If the encrypted password is arbitrarily derived, then it too needs to be included in the user record.

[0090] The above steps can be further simplified if the recognition of the authentication fob in step 601C prompts the safe immediately to add a new user with an assumed role.

[0091] Upgrading a user's permissions to a higher level of access can also be performed locally at the safe. This upgrade requires either a temporary code, an appropriately configured authentication fob, or the presentation of a credential of higher permission level to the new upgraded access level being granted.

[0092] As shown in process 700 of FIG. 7, in step 702, the user presents a fob to the safe.

[0093] In step 703, the fob's and user's registration status is determined.

[0094] If the user is a pre-registered new user or has modified user permissions, in step 704, the safe prompts the user for authentication following one of the previously discussed 2FA methods 601A-601C at the safe.

[0095] In step 706, if the user presents a valid 2FA credential, then the new user and the fob are fully registered.

[0096] If at step 703 or step 706, the registration status is none or valid 2FA authentication is not presented, then access is denied in step 710.

[0097] If at step 703, the registration status is determined to be fully registered and unmodified permissions, then in step 712, the user can conduct authorized activity at the safe.

[0098] One example is illustrated in step 714, in which the user adds a new user of lesser privilege level.

[0099] In step 716, the new user electronic fob is presented to the safe and in step 718, the new user is fully registered.

[0100] The safe transmits new user data to the networked database 152 in step 720.

[0101] FIG. 8 shows a process 800 which illustrates a user experience at the safe with an authentication fob. In step 802, an authentication fob is presented at the safe. If in step 804, the authentication fob is not recognized, then access is denied in step 806. If at step 804, the authentication fob is recognized, the user is prompted in step 808 to enter user data. In step 810, the new user electronic fob is presented to the safe, and in step 812, the new user is now fully registered. In step 814, the safe transmits the new user data to the network.

[0102] In process 900 of FIG. 9, the user experience at the safe using a temporary code is illustrated. In step 902, a temporary code is presented to the safe. For example, the temporary code is keyed in using a keypad such as 1014 in FIG. 10 after selecting an add new user mode. In step 904, if the temporary code is not recognized as valid, then access is denied in step 906. If in step 904 the temporary code is recognized as valid, then in step 908, the user is prompted to enter user data. In step 910, the new user electronic fob is presented to the safe. In step 912, the new user is now fully registered. In step 914, the safe transmits the new user data to the network.

[0103] In contrast with the first embodiment's two-part registration process, process 600 does not accept a peer-level credential to add users, they must be of higher permission level. This process also has a drawback of entering user metadata at the safe which may be more tedious for larger enterprises where that data is easier to port from a database. For smaller CIT operations or operations with less central administration staff in place, this second method more easily accommodates ad hoc user creation while still maintaining similar levels of protection against malicious intent.

[0104] FIG. 10 shows an exemplary programmed control processor and illustrative peripherals of a control system 1000 for one embodiment implementing an electronic safe, such as one of the safes 110 of FIG. 1. While an electronic drop safe is shown, it will be recognized that the present invention may suitably be employed with a wide range of electronic smart safes characterized by having electronic locks to gain access to valuables and data stored therein, as well as access to provide service to safe components; time stamps to record events such as deposits, service calls, safe openings, collections and the like; and at least part time network communication with a central server or database. Further details of electronic safes and electronic locks for safes with which the present invention may be advantageously adapted and employed are found in U.S. Patent Application Publication Nos. 2002/0063034; 2004/0046018; 2011/0279225; 2011/0011927; 2016/0010939; 2020/0056218; and U.S. Pat. Nos. 7,516,832; 7,779,983; 8,770,372; and 10,584,515 all of which are assigned to the assignee of the present invention and incorporated by reference herein in their entirety.

[0105] In FIG. 10, processor 1010 drives display 1012 to display prompts to a user including a prompt to a first-time user for authentication, a menu of roles and the like. A keypad or keyboard 1014 is utilized by the user to enter an OTC, user metadata and the like.

[0106] An electronic lock or locks 1016 are controlled by processor 1010 to control access to valuables, such as cash, components that require servicing and the like. Preferably, a BLE transmitter and receiver 1018 is controlled by processor 1010 to receive communications from a fob, such as one of the fobs 180 or an authenticator fob 190. Fob transceiver 1018 alternatively can take the form of other RF transceivers compatible with the various RF fobs described and may be one and the same as the network transceiver 1019. The network connection 1019 is used to communicate with a network such as network 120 to communicate details of new user fob registration and the like. Network transceiver 1019 is preferably a cellular modem, but could be other connection means such as an Ethernet connection, or a WiFi connection to the database 152.

[0107] Processor 1010 receives clock inputs from clock 1030 which it employs in time stamping events deemed to be significant, such as cash collection, cash deposits, service events, fob registration, permission modifications and the like. Control system 1000 may also optionally include a physical fob connection such as a iButton port or USB port 1050. A bill validator and stacker 1060 may be advantageously employed to validate currency inserted into an electronic safe and stack same for easy pick up. The time of insertion of currency and the amount of any such insertion are reported to the processor 1010 and these events are time stamped as well as ay door openings for service of the safe.

[0108] Control system also includes memory including program storage 1020 and data storage 1040. The exemplary program storage 1020 includes program instructions arranged in modules, such as a module 1021 to control the processor 1010 to determine the validity of temporary codes, a module 1022 to control the processor to determine the validity of an administrator fob, a module 1023 to determine validity of either a higher permission fob or a same permission fob, a module 1024 to control the processor to recognize and authenticate a new user fob. A module 1025 to manage collection and storage of time stamp data, and a module 1026 to collect data regarding stored valuables.

[0109] The data storage memory 1040 stores data fields including filed 1042 storing time stamp data, field 1044 storing user data, field 1046 storing fob data, and field 1048 storing safe menu to add new user data, and field 1049 the new controller configuration flag for accepting a list of users as fully registered while asserted.

[0110] While the disclosure has been set forth herein in reference to specific aspects, features and illustrative embodiments, it will be appreciated that the utility of the disclosure is not thus limited, but rather extends to and encompasses numerous other variations, modifications and alternative embodiments, as will suggest themselves to those of ordinary skill in the field of the present disclosure, based on the description herein. Correspondingly, the disclosure as hereinafter claimed is intended to be broadly construed and interpreted, as including all such variations, modifications and alternative embodiments, within its spirit and scope.