Abstract:
Embodiments are directed to simulating an operation of a mechanical lock in an electronic context, comprising: applying a contactless wireless credential to a lock, authenticating the credential, unlocking the lock to provide access to a resource protected by the lock based on having authenticated the credential, determining a security level associated with the lock, and conditionally capturing the credential based on the security level.

Description:
BACKGROUND 
       [0001]    Current electronic locks fail to provide an ability to capture a key when the lock is operated. In a mechanical lock, the key is captured after the key is placed into the lock and rotated away from the “zero” position; after beginning rotation, the key cannot be removed from the lock except when placed in some predetermined positions. Virtually all mechanical locks operate in this manner, and so, users have been conditioned to rotate the key to one of the predetermined positions in order to remove their key. In a mechanical lock context, it is rare for a user to unintentionally leave the key in the lock. 
         [0002]    In contactless (and most contact-based) electronic locking applications, the key is not captured by the lock while it is operated, and there is minimal incentive for a user to return to the locked state after completing a task. As a result, it is more common for electronic locks to be unintentionally left open relative to mechanical locks, thereby reducing security in an electronic context. Additionally, because of this weakness of being left unlocked, electronic locks are often designed with an ability to re-lock themselves, which ability requires more expensive designs including more batteries if a lock is wireless. 
       BRIEF SUMMARY 
       [0003]    An embodiment of the disclosure is directed to a method for simulating an operation of a mechanical lock in an electronic context, comprising: applying a contactless wireless credential to a lock, authenticating the credential, unlocking the lock to provide access to a resource protected by the lock based on having authenticated the credential, determining a security level associated with the lock, and conditionally capturing the credential based on the security level. 
         [0004]    An embodiment of the disclosure is directed to an apparatus comprising: at least one processor, and memory having instructions stored thereon that, when executed by the at least one processor, cause the apparatus to: receive an electronic credential to be applied to a lock, receive an indication that the lock has authenticated the credential, determine a security level associated with the lock, capture the credential when the security level is of a pre-defined security level, and restrict access to a second resource during a time when the credential is captured. 
         [0005]    Additional embodiments are described below. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements. 
           [0007]      FIG. 1  is a schematic block diagram illustrating an exemplary computing system in accordance with one or more embodiments; 
           [0008]      FIG. 2A  illustrates an exemplary mobile phone environment for enforcing a security policy in accordance with one or more embodiments; 
           [0009]      FIG. 2B  illustrates an exemplary mobile phone environment for enforcing a security policy in accordance with one or more embodiments; 
           [0010]      FIG. 3  illustrates a flow chart of an exemplary method in accordance with one or more embodiments; and 
           [0011]      FIG. 4  illustrates a flow chart of an exemplary method in accordance with one or more embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    It is noted that various connections are set forth between elements in the following description and in the drawings (the contents of which are included in this disclosure by way of reference). It is noted that these connections in general and, unless specified otherwise, may be direct or indirect and that this specification is not intended to be limiting in this respect. In this respect, a coupling between entities may refer to either a direct or an indirect connection. 
         [0013]    Exemplary embodiments of apparatuses, systems, and methods are described for enhancing security of electronic locks. In some embodiments, a key capture associated with a mechanical lock may be mimicked or simulated in an electronic context. A locked state in the electronic lock may be regulated or enforced by a policy. Different levels of security may be associated with the policy. In some embodiments, a contactless wireless key may interact with an electronic lock. 
         [0014]    Referring to  FIG. 1 , an exemplary computing system  100  is shown. The system  100  is shown as including a memory  102 . The memory  102  may store executable instructions. The executable instructions may be stored or organized in any manner and at any level of abstraction, such as in connection with one or more processes, routines, procedures, methods, etc. As an example, at least a portion of the instructions are shown in  FIG. 1  as being associated with a first program  104   a  and a second program  104   b.    
         [0015]    The instructions stored in the memory  102  may be executed by one or more processors, such as a processor  106 . The processor  106  may be coupled to one or more input/output (I/O) devices  108 . In some embodiments, the I/O device(s)  108  may include one or more of a keyboard or keypad, a touchscreen or touch panel, a display screen, a microphone, a speaker, a mouse, a button, a remote control, a joystick, a printer, a telephone or mobile device (e.g., a smartphone), etc. The I/O device(s)  108  may be configured to provide an interface to allow a user to interact with the system  100 . 
         [0016]    The system  100  is illustrative. In some embodiments, one or more of the entities may be optional. In some embodiments, additional entities not shown may be included. For example, in some embodiments the system  100  may be associated with one or more networks. In some embodiments, the entities may be arranged or organized in a manner different from what is shown in  FIG. 1 . One or more of the entities shown in  FIG. 1  may be associated with one or more of the devices or entities described herein. 
         [0017]      FIG. 2A  illustrates an exemplary mobile phone system environment  200  for enforcing a security policy. While the system  200  is depicted in  FIG. 2A  as being based on a phone  202  (e.g., a mobile phone), other types of components or devices may be used in some embodiments. For example, in some embodiments a smart card may be presented to a ‘reader’ that is associated with a lock. In some embodiments, a (proprietary) FOB ID type of device may be configured with one or more interfaces (e.g., a display and buttons) that may enable a user to interact with a lock. The system  200  may be used to electronically simulate a key capture function of mechanical locks. 
         [0018]    As shown in  FIG. 2A , the phone  202  is associated with a key  204 . The key may correspond to a credential that may be used to obtain access to a task or function associated with the phone  202 . Much like a key used in a mechanical lock operation, a user&#39;s ability to access the task/function may be conditioned on a presentation or use of an appropriate key  204  to a lock  206 . In some embodiments, the key  204  may correspond to, or include, a key fob. 
         [0019]    While the key  204  and lock  206  are shown in  FIG. 2A  as being present on the phone  202 , in some embodiments one or both of the key  204  and the lock  206  may be present at another device or location (e.g., a server). For example,  FIG. 2B  illustrates an embodiment where the lock  206  is located external to the phone  202 . In some embodiments, the lock  206  may correspond to a physical, electro-mechanical lock. 
         [0020]    One or more devices may be communicatively coupled to one another via one or more networks, such that a key (e.g., key  204 ) present at a first device (e.g., phone  202 ) may be presented to a lock (e.g., lock  206 ) located at a second device. 
         [0021]    In some embodiments, the key  204  may be communicated by the phone  202  using one or more communication techniques. For example, near field communication (NFC), Bluetooth, or another transmission (e.g., another wireless transmission) may be used. 
         [0022]    Operation of the lock  206  may be associated with a security policy. The policy may be enforced at any level of computing abstraction. For example, the policy may be enforced with respect to a device (e.g., phone  202 ), a task or function associated with a device, an input or output to a device, etc. 
         [0023]    The policy may have a number of levels associated with it. For example, as shown in  FIGS. 2A and 2B , the policy may have low  208   a,  medium  208   b,  and high  208   c  levels of security. In some embodiments, more or less than three levels of security may be used. A selection of which security level  208   a - 208   c  to use may be a function of the lock  206 , or more specifically, a resource (e.g., data or information) that the lock  206  serves to protect or provide conditional access to. 
         [0024]    The security levels  208   a - 208   c  may be associated with one or more actions with respect to the lock  206  in regards to the state of the lock  206 . For example, if the selected security level is low  208   a,  the user may present the key  204  to unlock the lock  206 . The user may be responsible for re-locking the lock  206  when the task/function is complete, but the user might not receive any notification or reminder that the lock  206  is unlocked. Thus, the re-locking of the lock  206  may be left to the user&#39;s discretion  210   a.    
         [0025]    If the selected security level is medium  208   b,  the user may present the key  204  to unlock the lock  206 . The user may gain access to the task/function protected by the lock  206  based on having presented the key  204 , but might be precluded from performing any other operations until the lock  206  is re-locked. In this respect, a key-capture function associated with mechanical locks may be simulated, as the user&#39;s credentials may effectively be revoked until a re-lock status is indicated. Furthermore, the user may have an incentive to restore the lock  206  to the locked state after completing the task/function in order to gain access to the other operations. 
         [0026]    In the medium security level  208   b,  the phone  202  may generate a prompt  210   b  (e.g., a displayed message, an auditory sound, etc.), potentially as a function of a timeout. The timeout may be based on a time that the lock  206  is in the unlocked state, an amount of activity or interaction (or lack thereof) with respect to the task/function, or some other condition. The prompt  210   b  may request the user to re-lock the lock  206 , but might not actually confirm that the lock  206  has been re-locked. In some embodiments, the prompt  210   b  may persist until the user provides an indication that the user received the prompt  210   b.  For example, if the prompt  210   b  includes a displayed message (e.g., a pop-up message), the message may continue to be displayed until the user pushes, e.g., a key or button that indicates the user saw the message, at which point the message may then be removed from the display. 
         [0027]    If the selected security level is high  208   c,  when the user presents the key  204  to unlock the lock  206  the user may gain access to the task/function protected by the lock  206 , but might be precluded from performing any other operations until the lock  206  is re-locked similar to use of the medium security level  208   b  described above. However, the high security level  208   c  may include an additional layer of security. For example, rather than merely providing a prompt (e.g., prompt  210   b ) to the user to confirm that the lock  206  has been re-locked as in the medium security level  208   b,  in the high security level  208   c  the phone  202  may communicate with the lock  206  to confirm or verify that the user has re-locked the lock  206 . The communication may take one or more forms. In some embodiments, the lock  206  may include one or more sensors that may provide a status (e.g., locked or unlocked) of the lock  206  to the phone  202 . In some embodiments, a database associated with phone (e.g., cell phone) operations or functions may be consulted to confirm that the lock  206  is re-locked. In short, any technique may be used to confirm that the lock  206  is re-locked. Until the phone  202  verifies that the lock  206  is re-locked, the user&#39;s credentials may be effectively revoked. 
         [0028]    Turning to  FIG. 3 , a flow chart of an exemplary method  300  is shown. The method  300  may execute in connection with one or more systems, components, or devices, such as those described above with respect to  FIGS. 1-2 . The method  300  may be executed to simulate a capture and/or control of a key in an electronic context. The method  300  may be executed to enforce a security policy. 
         [0029]    Block  302  may correspond to an idle state of operation, and a lock (e.g., lock  206  of  FIGS. 2A and 2B ) may be in a locked state. Flow may continue to stay in block  302  until one or more credentials are received. The credentials may include a presentation of a key (e.g., key  204 ). In some embodiments, the credentials may include use of a gesture in front of a lock or lock core. For example, a hand gesture may be used when a phone is in hand. In some embodiments, the credentials may include one or more of a username, a password, a personal identification number (PIN), or a digital certificate. A credential may include a security policy and/or a user security level. For example, a digital certificate, which has a signature, may include information (e.g., a security policy), may be signed by a trusted authority (e.g., a server), and may be distributed to a user. The user may use the certificate as a ‘key’ to present to a lock. The certificate may include the security policy, permissions, etc. If the credential(s) are verified or authenticated, flow may proceed from block  302  to block  304 . 
         [0030]    In block  304 , a determination may be made regarding a state of a requested operation (op). If the requested operation indicates an opening of the lock, flow may proceed from block  304  to block  306 . Otherwise, if the requested operation indicates a verification of a locked state with respect to the lock, flow may proceed from block  304  to block  308 . 
         [0031]    In block  306 , the lock may be unlocked for an amount of time. The amount of time may be based on one or more conditions or events and may be a function of a selected level of security. Flow may continue to stay in block  306  until the amount of time expires (timeout), at which point flow may proceed from block  306  to block  310 . 
         [0032]    In block  310 , a determination may be made whether the lock is locked. A determination that a lock is locked may correspond to a determination of one or more of: (1) that a lock core itself is locked, (2) that a user or an automated return mechanism turned a lock core such that an attached lock mechanism is locked, and (3) that a user or an automated return mechanism turned a lock core but a lock mechanism remained unlocked (e.g., on a door a deadbolt can be locked without the door locking because the door is left open). If the determination of block  310  indicates that the lock is locked, flow may proceed from block  310  to block  302 . Otherwise, if the lock is unlocked, flow may proceed from block  310  to block  312 . 
         [0033]    In block  308 , a determination may be made whether the lock is locked. Similar considerations for determining whether a lock is locked as described above in connection with block  310  may be applied in connection with block  308 . If the lock is locked, a transmission of the locked state of the lock may be provided (tx locked), and flow may proceed from block  308  to block  302 . Otherwise, if the lock is unlocked, a transmission of the unlocked state of the lock may be provided (tx unlocked) and flow may proceed from block  308  to block  312 . 
         [0034]    Block  312  may correspond to an idle state of operation, and the lock may be in an unlocked state. Flow may continue to stay in block  312  until one or more credentials are received or the lock is locked. If one or more credentials are received, and the credentials are verified or authenticated, then flow may proceed from block  312  to block  304 . Otherwise, if the lock is locked, flow may proceed from block  312  to block  302 . 
         [0035]    Turning now to  FIG. 4 , a flow chart of an exemplary method  400  is shown. The method  400  may execute in connection with one or more systems, components, or devices, such as those described above with respect to  FIGS. 1-2 . The method  400  may be executed to simulate a capture and/or control of a key in an electronic context. The method  400  may be executed to enforce a security policy. 
         [0036]    In block  402 , one or more credentials may be received. The credentials may be associated with a lock that may provide conditional access to one or more resources. 
         [0037]    In block  404 , the received credentials may be authenticated or verified. If the credentials are valid, flow may proceed to block  406 . Otherwise, if the credentials are invalid, flow may proceed back to block  402 . In some embodiments, as part of the flow from block  404  to block  402  a counter may be incremented. The counter may be used to limit the number of attempts or tries that a user has to present valid credentials in order to increase security. When the value of the counter is greater than a threshold, a user may be prohibited from accessing the resource(s). 
         [0038]    In block  406 , the lock may be unlocked based on receipt of the valid credentials. Access to the one or more resources may be obtained based on the unlocking of the lock. If a selected security level is at a particular level (e.g., medium  208   b  or high  208   c  of  FIGS. 2A and 2B ), then the credential (e.g., key  204  of  FIGS. 2A and 2B ) may be captured. The capture of the credential may prohibit the use of other resources (e.g., other tasks or functions) until the lock is (re)locked. 
         [0039]    One or more entities or devices may be configured to determine a security level and/or capture a credential. In some embodiments, a phone may determine a security level based on a credential itself (e.g., if the credential is a digital certificate) and the phone may capture the credential and not allow it to be used. 
         [0040]    In some embodiments, a lock may determine a security level and inform a phone, and in response, the phone may capture a credential until the phone receives a message (from the user in a medium security level regime or from the lock in a high security level regime) that the lock is re-locked. 
         [0041]    In some embodiments, a lock may determine a security level and the lock may capture a credential by writing to a phone or a smart card and permanently modify the credential until the lock is re-locked. Once the lock is re-locked, the lock may re-write a new credential that indicates that it is acceptable for use again. 
         [0042]    In some embodiments, an indication may be sent to a server by, e.g., a lock or by a phone, that the lock is unlocked. The server may generate a message that disables a credential until a second indication is sent/received that indicates that the lock is re-locked. Based on the second indication, the server may generate a second message that releases the credential. The second message that releases the credential could be received by the phone and an application on the phone may prohibit use of the credential until released. Additionally, or alternatively, one or more messages may be sent to the lock and the lock may capture the credential. 
         [0043]    Referring back to  FIG. 4 , in block  408 , a determination may be made regarding an indication of the state of a lock (e.g., an indication from a user, potentially responsive to a prompt  210   b,  if using a medium security level  208   b,  or actual verification of a locked state  210   c  if using a high security level  208   c ). If the lock is unlocked, then flow may proceed from block  408  back to block  406 , at which point access to the resource(s) protected by the lock may continue to be provided; however, access to other resources may be restricted if the credentials were captured. Otherwise, if the lock is locked, then flow may proceed from block  408  to block  402 , at which point access to the resource(s) protected by the lock may be restricted and the credentials may be released if they were captured as part of block  406 . 
         [0044]    The methods  300  and  400  are illustrative. In some embodiments, one or more of the blocks or operations (or portions thereof) may be optional. In some embodiments, additional operations not shown may be included. In some embodiments, the operations may execute in an order or sequence different from what is shown. 
         [0045]    Embodiments of the disclosure may be tied to one or more particular machines. For example, one or more devices, apparatuses, systems, or architectures may be configured to provide conditional access to a resource based on a state of a lock. A credential or key may be captured as part of unlocking the lock, which may provide an incentive to a user to restore the lock to the locked state once the user is done with the resource. In this respect, the likelihood or probability of a user unintentionally leaving an electronic lock in an unlocked state may be reduced, which may help to improve or enhance security. 
         [0046]    Embodiments of the disclosure may be implemented in accordance with a distributed computing environment. Such an environment may be used to facilitate multi-user operations, optionally as a part of one or more networks (e.g., social networks). For example, a first user associated with a first device may unlock a lock in order to access a resource (e.g., to work on a given task or function), and a second user associated with the first device or a second device may restore the lock to a locked state. In some embodiments, one or more permission schemes or techniques may be employed to determine various user access rights with respect to a lock or a resource. 
         [0047]    As described herein, in some embodiments various functions or acts may take place at a given location and/or in connection with the operation of one or more apparatuses, systems, or devices. For example, in some embodiments, a portion of a given function or act may be performed at a first device or location, and the remainder of the function or act may be performed at one or more additional devices or locations. 
         [0048]    Embodiments may be implemented using one or more technologies. In some embodiments, an apparatus or system may include one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus or system to perform one or more methodological acts as described herein. Various mechanical components known to those of skill in the art may be used in some embodiments. 
         [0049]    Embodiments may be implemented as one or more apparatuses, systems, and/or methods. In some embodiments, instructions may be stored on one or more computer-readable media, such as a transitory and/or non-transitory computer-readable medium. The instructions, when executed, may cause an entity (e.g., an apparatus or system) to perform one or more methodological acts as described herein. 
         [0050]    Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps described in conjunction with the illustrative figures may be performed in other than the recited order, and that one or more steps illustrated may be optional.