Optimization of flexible distributed tokens in an access control system

Abstract

A method according to an embodiment includes determining whether a guest associated with a guest device is authorized to control an access control device based on an access control list, generating a warning cryptographic bearer token in response to the determination that the guest is authorized to control the access control device, said warning cryptographic bearer token includes a time-based warning that defines a time limit for controlling the access control device, transmitting the warning cryptographic bearer token to the guest device in response to the generation of the warning cryptographic bearer token, transmitting, in response to receiving the warning cryptographic bearer token, a request that includes the warning cryptographic bearer token to control the access control device to the access control device.and authenticate the request based on the received cryptographic bearer token with warning, a base cryptographic bearer token stored on the access control device, and a real-time clock from the access control device.

Description

Optimization of flexible distributed tokens in an access control system PRIOR ART Access control systems typically involve the use of credentials to manage the operation of an access control device (e.g., a lock). These credentials can be assigned to a specific user or device and are often physical in nature, forming at least part of, for example, a smart card, proximity card, key fob, token device, or mobile device. In addition, an access control database is usually stored on the access control device or on a server that communicates with it. This database identifies which credentials (e.g., which user devices) are authorized to control the access control device (e.g., its locking and unlocking functions).Therefore, an access control database update to change the credentials associated with the access control device, if possible, usually involves updating (or even resetting to factory settings) the access control device itself. US Patent 20160358397 A1 discloses access control to a location, where access to the location is restricted by a locking mechanism. US Patent 2010 306549 A1 discloses a method for managing access control using locking units, particularly locks, and electronic keys, wherein access authorizations are stored and managed in a central processor; keys are programmed, based on the respective access authorization, with authorization information for a predetermined selection of locking units; in the event of an access request, the authorization information is wirelessly transmitted from a key to a locking unit; and access authorization is determined in the locking unit based on the authorization information received.US Patent 2016 0019735 A1 relates generally to locking devices and, more specifically, to a method and system for a wirelessly enabled locking device. WO Patent 2013 / 090211 A2 relates to a technology described for controlling a security device that provides access to a restricted resource. DE Patent 20 2017 100417 U1 discloses computerized methods used in low-power networks for remotely operated devices that can be controlled using secure, direct wireless connections. CHARACTERISTICS The invention discloses a procedure and an access control system as set forth in the independent claims. BRIEF DESCRIPTION OF THE DRAWINGS The concepts described in this document are illustrated by way of example, and not as a limitation, in the accompanying figures. To simplify and enhance clarity, the elements shown in the figures are not necessarily drawn to scale. Where deemed appropriate, numerical references have been repeated in the various figures to indicate corresponding or analogous elements. Figure 1 is a simplified block diagram of at least one implementation of an access control system for flexible distributed token optimization; Figure 2 is a simplified block diagram of at least one implementation of a computer system; Figure 3 is a simplified block diagram of at least one implementation of a procedure for registering a lock device; Figure 4 is a simplified block diagram of at least one implementation of a procedure for updating an access control list; and Figure 5 is a simplified block diagram of at least one implementation of a procedure for controlling a lock device by a guest device. DETAILED DESCRIPTION The present invention discloses a method and access control system as set forth in the appended independent claims. Although the concepts of the present invention are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. References in the specification to "an embodiment," "an illustrative embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, although not all embodiments necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. It should also be understood that although a reference to a "preferred" component or feature may indicate the desirability of a particular component or characteristic with respect to one embodiment, the invention is not thereby limited with respect to other embodiments, which may omit that component or characteristic. Moreover, when a particular feature, structure, or characteristic is described in relation to one embodiment, a person skilled in the art is deemed to know how to implement that feature, structure, or characteristic in relation to other embodiments, whether or not they are explicitly described.Additionally, it should be understood that the elements included in a list in the form of "at least one of A, B, and C" can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C). Similarly, the elements listed in the form of "at least one of A, B, or C" can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C). Furthermore, with respect to the claims, the use of words and phrases such as "a", "an", "at least one" and / or "at least a part" should not be construed as limiting to only one of such elements unless specifically stated otherwise, and the use of phrases such as "at least a part" and / or "a part" should be construed as encompassing both embodiments that include only a part of such element and embodiments that include the whole of it unless specifically stated otherwise. The disclosed embodiments may, in some cases, be implemented in hardware, firmware, software, or a combination thereof. The disclosed embodiments may also be implemented by means of instructions carried by, or stored on, one or more transient or non-transient machine-readable (e.g., computer-readable) storage media, which can be read and executed by one or more processors. A machine-readable storage medium may be realized as any storage device, mechanism, or other physical structure for storing or transmitting information in a machine-readable form (e.g., volatile or non-volatile memory, a storage disk, or other media device). In the drawings, some structural or procedural features may be depicted in specific arrangements and / or orderings. However, it should be understood that such specific arrangements and / or orderings may not be required. Rather, in some embodiments, such features may be arranged in a manner and / or order different from those shown in the illustrative figures unless otherwise indicated. Furthermore, the inclusion of a structural or procedural feature in a particular figure does not imply that such feature is required in all embodiments, and in some embodiments, it may be omitted or combined with other features. Referring now to Figure 1, in the illustrative embodiment, an access control system 100 for flexible distributed token optimization includes a lock device 102, an owner device 104, a cloud server 106, and a guest device 108. Additionally, in some embodiments, the access control system 100 may also include a gateway device 110. As described in detail below, the access control system 100 enables flexible access control over offline lock devices 102 and / or other access control devices. For example, in some embodiments, the owner of a lock device 102 can invite others (guests) into a facility without having a connection to the facility's locks and / or readers. To do this, the access control system 100 uses a connection to a cloud server 106 that distributes conditional bearer cryptographic tokens (e.g., macaroons) to the owner's device 104 and / or guest devices 108 for use with a specific lock device 102.It should also be understood that the lock device 102 of the access control system 100 is not limited, for example, by the number of guests who can control the lock device 102 and / or other limitations associated with finite onboard memory, because the lock device 102 does not need to locally store an access control list of authorized users. Instead, as described herein, the lock device 102 stores a base macaroon (or other base cryptographic bearer token), which is compared (for example, directly or indirectly) with derived macaroons or contextual cryptographic bearer tokens to determine whether a particular user / device should be granted access or control permission. In the illustrative embodiment, access control system 100 leverages the flexibility associated with contextual bearer cryptographic tokens (e.g., macaroons) for access control. As described below, the lock device 102 and the owner device 104 communicate with each other during a setup or registration process in which a base bearer cryptographic token (e.g., a base macaroon) is generated with an initial set of restrictions (e.g., a start date / time of validity, a particular security model, etc.). Once generated and sent to the cloud server 106, the cloud server 106 adds further conditions to the base bearer cryptographic token and its restrictions, either to shorten the period during which the token is valid or to limit the permissions granted to a particular user / guest.In particular, in doing so, cloud server 106 employs a cryptographic hash function (e.g., an HMAC) to apply a hash function to the additional conditions on the base bearer cryptographic token to generate a derived or conditional bearer cryptographic token (e.g., a derived macaroon). It should be understood that, in the illustrative embodiment, the additional conditions can only modify the base token to make it more restrictive than the ase token, preventing a guest, for example, from gaining higher privileges than the owner of lock device 102. As shown in Figure 1, the illustrative owner device 104 includes an application 112 that allows the lock owner to register an account on the cloud server 106 or the associated cloud service. In the illustrative embodiment, the owner's secure login (e.g., username and password) to the cloud server / service constitutes a separate security domain from the security domain associated with the flexible tokens described herein. The application 112 further provides a user interface through which the owner can enter user inputs associated with registering a particular lock device 102 to the owner.Additionally, in some embodiments, after the base cryptographic bearer token (e.g., base macaroon) is generated and stored on the lock device 102 and cloud server 106, the token can be removed from the owner's device 104. In such embodiments, the owner can subsequently use application 112 to retrieve a conditional bearer token to access or control the lock device 102, in a manner similar to that described below with reference to a guest. Guest Device 108 also includes an application 114 that allows a particular guest to register an account with the cloud server / service, request and / or receive an invitation from the owner to access or control a particular lock device 102, request and / or receive conditional bearer cryptographic tokens (e.g., macaroons) to access or control particular lock devices 102, and interact with lock devices 102. Applications 112 and 114 can be any applications suitable for performing the functions described herein. For example, in some embodiments, the owner device 104 and the guest device 108 are implemented as mobile devices. In such embodiments, applications 112 and 114 can be implemented as mobile applications (e.g., smartphone applications). In some embodiments, it is understood that one or more of applications 112 and 114 can serve as a client-side user interface for a web-based application or service on the cloud server 106. As shown in Figure 1, the cloud server 106 includes an access control list 116. In the illustrative embodiment, access control list 116 identifies each lock device 102 registered with the cloud server / service, the owner of each of those lock devices 102, and the guests (if any) authorized to access each of those lock devices 102. In some embodiments, each user (e.g., owner / guest) may be associated with a universally unique identifier (UUID) generated during secure login to the cloud server 106 (e.g., generated as a JSON web token (JWT)). In such embodiments, it is understood that the owner and guests of a particular lock device 102 can be identified in access control list 116 by the corresponding UUID of that owner or guest.Each 102 lock device can be similarly identified based on a lock programming or security code and / or a unique lock identifier. For example, in some embodiments, each 102 lock device can be identified based on a lock programming code that is visually displayed on a component of the 102 lock device (e.g., the back of the 102 lock device), included in the documentation supplied with the 102 lock device after purchase, and / or stored in a securely transferable memory of the 102 lock device. In some implementations, access control list 116 can identify a memory location on the cloud server 106 from which the cryptographic token to the base bearer (e.g., base macaroon) corresponding to each of the registered lock devices 102 can be retrieved. In distributed environments, access control list 116 can also identify, for example, the IP address and / or the physical address of the device storing the token. It is understood that access control list 116 can be implemented as a table (e.g., an association table), a database, or any other data structure or collection of data structures suitable for performing the functions described herein. As described in detail below, in the illustrative embodiment, the owner device 104 and the guest device 108 are implemented as mobile devices, and the lock device 102 can communicate with the owner device 104 and the guest device 108 via any suitable wireless communication connection (e.g., Bluetooth, Wi-Fi, etc.) established between the lock device 102 and devices 104 and 108. Additionally, in the illustrative embodiment, the owner device 104 and the guest device 108 can communicate with the cloud server 106 using any suitable wireless communication connection. For example, in various embodiments, the owner device 104 and / or the guest device 108 can communicate with the cloud server 106 via Wi-Fi, WiMAX, a WAN (e.g., the internet), and / or a suitable telecommunications network / protocol.Therefore, it is understood that the illustrative cloud server 106 is located in one or more remote locations with respect to devices 102, 104, 108. In other embodiments, it is understood that one or more of the communication connections may be wired. In some embodiments, the access control system 100 may include the gateway device 110. For example, in some embodiments, the gateway device 110 may be used in third-party integrations with the access control system 100. In some embodiments, a registered gateway device 110 may be treated as an additional owner of the lock device 102 with owner-like privileges. Consequently, unlike guests, the gateway device 110 may receive a bearer cryptographic token that is not time-limited or permission-limited in some embodiments. In embodiments that include the gateway device 110, it is understood that the gateway device 110 may communicate with other devices of the access control system 100 via any suitable wired or wireless communication network and associated protocol. Furthermore, in some embodiments, one or more of the owner devices 104 and / or guest devices 108 may be implemented as a shared device or user interface device that enables a user to interact with the cloud server 106, the lock device 102, and / or cloud-based solutions. For example, one or more of the devices 104, 108, and 110 may be implemented as a home assistant device or smart home hub. In some embodiments, the access control system 100 may include an ambient voice interface or other shared user interface instead of a user-owned graphical user interface. Additionally, in some embodiments, the access control system 100 may be accessed through cross-cloud integration with a third-party integrator. It is understood that the lock device 102, the owner device 104, the cloud server 106, the guest device 108 and / or the gateway device 110 can be implemented as computing devices similar to the computing device 200 described below with reference to Figure 2. For example, in the illustrative embodiment, each of the lock device 102, the owner device 104, the cloud server 106, the guest device 108 and the gateway device 110 includes a processing device 202 and a memory 206 that stores operating logic 208 for execution by the processing device 202 during the operation of the corresponding device.Additionally, although locking device 102 is described herein, for the sake of clarity, as a "locking device," it should be understood that, in other embodiments, locking device 102 may be implemented as any access control device suitable for performing the functions described herein. Therefore, the description of locking device 102 is equally applicable to embodiments of access control system 100 that have a different type of access control device. It should also be understood that, although Cloud Server 106 is described herein as a cloud-based device or collection of devices, in other embodiments, Cloud Server 106 may be implemented as one or more devices outside of a cloud computing environment. Furthermore, in some embodiments, Cloud Server 106 may be implemented as a "serverless" computing solution, independent of a specific server, which, for example, executes multiple instructions on demand, contains logic to execute instructions only when a specific activity or trigger requests it, and does not consume computing resources when not in use.In other words, cloud server 106 can be implemented as a virtual computing environment residing "on" a computing system (e.g., a distributed network of devices) in which various virtual functions (e.g., Lambda functions, Azure functions, Google Cloud functions, and / or other suitable virtual functions) corresponding to the cloud server 106 functions described herein can be executed. For example, when an event occurs (e.g., a user presses a button in an application to unlock lock device 102), the application can contact the virtual computing environment (e.g., via an HTTPS request to a virtual computing environment API), so that the API can route the request to the correct virtual function (e.g., a compute resource independent of a specific server) based on a set of rules.Therefore, when a request is made for a conditional bearer cryptographic token, the appropriate virtual function or functions can be executed to determine whether that user should be granted access to lock device 102, issue the appropriate conditional bearer cryptographic token, and transmit that information to the user before removing the instance of the virtual function or functions. Although only one lock device 102, one owner device 104, one cloud server 106, one guest device 108, and one gateway device 110 are shown in the illustrative embodiment of Figure 1, the access control system 100 may include multiple lock devices 102, owner devices 104, cloud servers 106, guest devices 108, and / or gateway devices 110 in other embodiments. For example, as described herein, a particular owner may have multiple owner devices 104 that the owner can use to securely connect to the cloud server 106 (for example, via secure login over a security domain separate from the bearer cryptographic tokens) to register a lock device 102 and / or invite / revoke access control permissions for a particular guest on the lock device 102.Similarly, a guest with permission to access or control a particular lock device 102 can securely connect to the cloud server 106 via any suitable guest device 108 to request and receive a conditional bearer cryptographic token in order to access the lock device 102. Furthermore, in some embodiments, a particular owner and / or guest may have access to multiple lock devices 102. Therefore, it should be understood that, in some embodiments, a particular user may be an owner of one lock device 102 and a guest with respect to another lock device 102. Likewise, a particular device may be an owner device 104 or a guest device 108 depending on the individual (and their login credentials) using the device.In some embodiments, the cloud server 106 may be understood to be implemented as multiple servers in a cloud computing environment. Consequently, in such embodiments, the access control list 116 and / or other data used by the access control system 100 may be distributed across multiple servers. Referring now to Figure 2, a simplified block diagram of at least one embodiment of a computing device 200 is shown. The illustrative computing device 200 shows at least one embodiment of a lock device, owner device, cloud server, guest device and / or gateway device that can be used in connection with the lock device 102, owner device 104, cloud server 106, guest device 108 and / or gateway device 110 illustrated in Figure 1.Depending on the particular embodiment, the 200 computing device can be implemented as a reader device, credential device, access control device, server, desktop computer, tablet computer, laptop, netbook, Ultrabook™, mobile computing device, mobile phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (IoT) device, control panel, processing system, router, gateway, and / or any other computing, processing, and / or communication device capable of performing the functions described herein. The computing device 200 includes a processing device 202 that executes algorithms and / or processes data according to the operating logic 208, an input / output device 204 that enables communication between the computing device 200 and one or more external devices 210, and a memory 206 that stores, for example, data received from the external device 210 through the input / output device 204. The input / output device 204 enables the computing device 200 to communicate with the external device 210. For example, the input / output device 204 may include a transceiver, a network adapter, a network card, an interface, one or more communication ports (e.g., a USB port, serial port, parallel port, analog port, digital port, VGA, DVI, HDMI, FireWire, CAT 5, or any other type of communication port or interface), and / or other communication circuitry. The communication circuitry of the computing device 200 may be configured to use one or more communication technologies (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, etc.) to effect such communication, depending on the particular computing device 200.The input / output device 204 may include hardware, software and / or firmware suitable for performing the techniques described herein. External Device 210 can be any type of device that allows data to be input to or output from the computing device 200. For example, in various embodiments, External Device 210 can be implemented as the lock device 102, the owner device 104, the cloud server 106, the guest device 108, and / or the gateway device 110. Furthermore, in some embodiments, External Device 210 can be implemented as another computing device, switch, diagnostic tool, controller, printer, display, alarm, peripheral device (e.g., keyboard, mouse, touchscreen, etc.), and / or any other computing, processing, and / or communication device capable of performing the functions described herein. Additionally, in some embodiments, External Device 210 is understood to be integrated into the computing device 200. The processing device 202 can be implemented as any type of processor or processors capable of performing the functions described herein. In particular, the processing device 202 can be implemented as one or more single-core or multi-core processors, microcontrollers, or other processing / control circuitry. For example, in some embodiments, the processing device 202 may include, or be implemented as, an arithmetic logic unit (ALU), a central processing unit (CPU), a digital signal processor (DSP), and / or other suitable processor or processors. The processing device 202 can be programmable, a dedicated state machine implemented by hardwiring, or a combination thereof. Processing devices 202 with multiple processing units can utilize distributed, pipelined, and / or parallel processing in various embodiments.Furthermore, the processing device 202 may be dedicated solely to performing the operations described herein, or it may be used in one or more additional applications. In the illustrative embodiment, the processing device 202 is programmable and executes algorithms and / or processes data according to the operating logic 208 defined by programming instructions (such as software or firmware) stored in memory 206. Alternatively, the operating logic 208 for the processing device 202 may be at least partially defined by hardwired logic or other hardware. In addition, the processing device 202 may include one or more components of any type suitable for processing signals received from the input / output device 204 or from other components or devices and for providing desired output signals.Such components may include digital circuits, analog circuits, or a combination of both. Memory 206 can be of one or more types of non-transient, computer-readable media, such as solid-state memory, electromagnetic memory, optical memory, or a combination thereof. Furthermore, memory 206 can be volatile and / or non-volatile, and in some embodiments, some or all of the memory 206 can be of a portable type, such as a disk, tape, memory stick, cartridge, and / or other suitable portable memory. In operation, memory 206 can store various data and software used during the operation of the computing device 200, such as operating systems, applications, programs, libraries, and drivers.It should be understood that memory 206 can store data manipulated by the operating logic 208 of the processing device 202, such as, for example, data representing signals received from and / or sent to the input / output device 204, in addition to, or instead of, storing programming instructions that define the operating logic 208. As shown in Figure 2, memory 206 can be included with the processing device 202 and / or coupled to the processing device 202, depending on the particular embodiment. For example, in some embodiments, the processing device 202, memory 206, and / or other components of the computing device 200 can form part of a system-on-a-chip (SoC) and be incorporated on a single integrated circuit chip. In some embodiments, various components of the computing device 200 (for example, the processing device 202 and the memory 206) can be communicatively coupled through an input / output subsystem, which can be implemented as circuits and / or components to facilitate input / output operations with the processing device 202, the memory 206, and other components of the computing device 200. For example, the input / output subsystem can be implemented as, or otherwise include, memory controller hubs, input / output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, cables, light guides, printed circuit board traces, etc.), and / or other components and subsystems to facilitate input / output operations. The computing device 200 may include other components or additional components, such as those commonly found in a typical computing device (e.g., various input / output devices and / or other components), in other embodiments. It is further understood that one or more of the components of the computing device 200 described herein may be distributed across multiple computing devices. In other words, the techniques described herein may be employed by a computing system that includes one or more computing devices. Additionally, although only a single processing device 202, I / O device 204, and memory 206 are shown illustratively in Figure 2, it is understood that a particular computing device 200 may include multiple processing devices 202, I / O devices 204, and / or memories 206 in other embodiments.Furthermore, in some embodiments, more than one external device 210 may be in communication with the computing device 200. In some embodiments, the illustrative locking device 102 includes a locking mechanism configured to control access through a passage. For example, in some embodiments, the locking mechanism may be configured to adopt a locked state, in which access through the passage is denied, or an unlocked state, in which access to the passage is permitted. In some embodiments, the locking mechanism includes a bolt, latch, lever, and / or other mechanism adapted to move between the locked and unlocked states and otherwise perform the functions described herein. However, it is understood that, in other embodiments, the locking mechanism may be implemented as any other mechanism suitable for controlling access through a passage. Referring now to Figure 3, in use, the access control system 100 can execute a procedure 300 to register a lock device 102. It should be understood that the particular blocks of procedure 300 are illustrated by way of example, and such blocks may be combined or split, added or removed, and / or reordered in whole or in part depending on the particular implementation, unless otherwise stated. The illustrative procedure 300 begins with block 302, in which a lock owner establishes a communication connection with the cloud server 106 via an owner device 104, and the cloud server 106 determines whether the lock owner is a new lock owner or a registered lock owner. It should be understood that the cloud server 106 may employ any suitable technique to do so.For example, in some implementations, a user interface presented on the owner's device (104) may ask the user if they are a registered lock owner (e.g., if they have an existing account on the cloud server) and, if so, request the user / owner's secure login information for the cloud server account. In such circumstances, procedure 300 advances to block 308. However, if cloud server 106 determines that the user / owner is a new lock owner (for example, a lock owner without an existing account on the cloud server), procedure 300 proceeds to block 304, where the lock owner registers with cloud server 106. Specifically, in block 306, the owner can create an account on the cloud server and a secure login to cloud server 106 or an associated cloud service. As described above, in the illustrative embodiment, the secure login is understood to be associated with a different security domain than the bearer cryptographic tokens.For example, as described above, each user (e.g., owner / guest) can be associated with a UUID generated during secure login to cloud server 106 (e.g., generated as a JWT token) for user identification by cloud server 106. In some implementations, the UUID may be based in part on the user's username and / or primary phone number. It should be understood that, in some implementations, secure login may require multi-factor authentication. In block 308, the cloud server 106 determines whether to register a particular lock device 102 in the owner's name. If so, procedure 300 proceeds to block 310, where the owner enters a lock programming code into application 112 of the owner's device 104. As mentioned earlier, in some embodiments, each lock device 102 can be identified, for example, based on a lock programming code displayed visually on a component of the lock device 102 (e.g., the back of the lock device 102) or included in the documentation supplied with the lock device 102 after purchase. The owner can then copy the programming code into application 112 of the owner's device 104.Additionally, in some embodiments, it is understood that the programming code can be programmed into the memory of the lock device 102. In such embodiments, the programming code can be securely transmitted to the owner's device 104, for example, for comparison with the programming code manually entered by the owner in application 112. It should be understood that the lock programming code can serve as proof to the lock device 102 and application 112 that the owner has possession of, and / or is authorized to configure / register, the lock device 102. In some embodiments, entering the lock programming code initiates a session to establish a secure pairing between the lock device 102 and the owner's device 104 (or application 112, in particular).For example, in some embodiments, lock device 102 and owner device 104 can perform a Secure Password Authenticated Key Exchange (SPAKE) based on the lock's programming code (e.g., where the lock's programming code serves as a SPAKE2 password), which may include the generation of one or more cryptographic base bearer tokens (e.g., macaroons) as described below. In particular, in some embodiments, lock device 102 can issue a client authentication token and a server authentication token, which may be included in or form part of one or more cryptographic base bearer tokens.The server authentication token can then be used to ensure that a device is indeed communicating with the appropriate Lock Device 102 and that Lock Device 102, for example, is not being spoofed by a malicious actor. The client authentication token can be used for secure access to Lock Device 102 and, for simplicity, may be referred to herein simply as the cryptographic bearer token (despite some embodiments of bearer tokens that include both the server authentication token and the client authentication token). As previously stated, in block 312, lock device 102 generates a base bearer cryptographic token (e.g., a base macaroon), for example, as part of a secure peering between lock device 102 and owner device 104 (or application 112, in particular). As described above, in the illustrative embodiment, the base bearer cryptographic token is generated by lock device 102 and securely transmitted to owner device 104 (e.g., encrypted by a SPAKE key). However, in other embodiments, it should be understood that the token may alternatively be generated by owner device 104 and transmitted to lock device 102. In block 314, the base bearer cryptographic token is stored on lock device 102 and cloud server 106.For example, in the illustrative embodiment, owner device 104 securely transmits the cryptographic token to the base bearer on cloud server 106 (for example, via application 112) and removes the token from owner device 104's memory. In block 316, access control list 116 on cloud server 106 is updated to identify the cryptographic token to the base bearer and the registered owner's ownership of lock device 102. For example, as noted above, in some embodiments, access control list 116 can be updated to identify a memory location on cloud server 106 from which the cryptographic token to the base bearer can be retrieved.Additionally, access control list 116 can be updated to associate the owner with lock device 102 (for example, by mapping the owner's UUID to a lock identifier of lock device 102). Although blocks 302-316 are described in a relatively serial manner, it should be understood that several blocks of procedure 300 can be implemented in parallel in some embodiments. Referring now to Figure 4, in use, the access control system 100 can execute procedure 400 to update an access control list 116. It should be understood that the particular blocks of procedure 400 are illustrated by way of example, and such blocks may be combined or split, added or removed, and / or reordered in whole or in part depending on the particular implementation, unless otherwise stated. The illustrative procedure 400 begins with block 402, in which the access control system 100 determines whether an owner wishes to update access control permissions for a particular lock device 102.For example, in some implementations, an owner can indicate a desire to update lock permissions via an application 112 running on the owner's device 104 (e.g., by selecting a particular option in the application, initiating a secure login, etc.). At block 404, the cloud server 106 verifies the lock owner via a secure login in a manner similar to that described above (e.g., via username / password over a security domain separate from the bearer cryptographic tokens).As noted above, in some implementations, the lock owner may be required to securely log in using multi-factor authentication and may therefore be required to, for example, enter a security code received via text message or email, provide biometric input, and / or otherwise provide proof of identity. Assuming the lock owner has been verified, in block 406, the cloud server 106 determines (for example, based on a user selection in application 112 of the owner's device 104) whether the owner wishes to invite a guest to have access control to the lock device 102 or revoke the access control permissions of a particular guest for a particular lock device 102. If the owner is inviting a guest to have access control through a particular lock device 102 (for example, based on user input), in block 408, the cloud server 106 transmits an invitation to a guest device 108 associated with the guest. It should be understood that the owner can identify the guest and / or the guest device 108 using any suitable identifier. For example, in some implementations, the owner can provide the guest's phone number and / or email address, to which the cloud server 106 can direct the invitation (for example, via voice, SMS, or email). Upon receiving the invitation, in block 410, the guest can securely log in to the cloud server 106 or the associated cloud service as described above.In particular, in some embodiments, by selecting a link provided in the invitation, the guest can be prompted to securely log in to cloud server 106 or to create a new account. In block 412, cloud server 106 updates access control list 116 to allow the guest access control to lock device 102. As described above, in the illustrative embodiment, guests are provided with time-limited and permission-limited access control, while the owner may have full access control over lock device 102, which is not time-limited (or is time-limited with a longer time limit).Having updated access control list 116 to allow guest access to lock device 102, cloud server 106 can subsequently issue temporary tokens (e.g., conditional bearer cryptographic tokens) to be given to the guest to access lock device 102, as described herein. In some embodiments, the temporary token may be understood to provide the guest with programmatic access. For example, the token may include a modified and / or additional time-based condition that establishes a time at which the token becomes valid, thereby providing a window within which the temporary token can be used (e.g., between the time at which it becomes valid and the time at which it expires). Returning to block 406, if the owner is revoking a guest's access control permissions for a particular lock device 102, in block 414, the cloud server 106 determines (for example, based on the owner's user input) the specific lock device 102 registered in the owner's name (if multiple lock devices 102 are registered in the owner's name) for which access controls should be modified, and the specific guest who currently has access control permissions to that lock device 102 that are to be revoked. In other words, in some implementations, the cloud server 106 determines the guest / lock combination whose access is to be revoked.In other embodiments, it is understood that the cloud server 106 can revoke a particular guest's access to all of the owner's lock devices 102 and / or revoke all guests' access to a particular lock device 102. In block 416, the cloud server 106 updates the access control list 116 to revoke the guest's access control for the particular lock device 102. For example, in some embodiments, the cloud server 106 removes the guest from an entry associated with the lock device 102 or otherwise unlinks the guest from the lock device 102.However, it should be understood that cloud server 106 may update access control list 116 to reflect the revocation using any suitable technique, which may vary depending on the particular implementation (e.g., depending on the particular data structure of access control list 116). It should be understood that, in the illustrative implementation, the revocation of the guest access control permission prevents cloud server 106 from subsequently issuing / transmitting a conditional bearer cryptographic token to a guest device 108 (unless it is currently associated with a different authorized guest as described above) to access lock device 102. In some embodiments, the cloud server 106 can update access control list 116 to grant and / or revoke multiple access control permissions simultaneously, depending on the owner's user input. In some embodiments, access control list 116 can also include a blacklist that defines one or more devices that are not authorized to receive a bearer cryptographic token under any circumstances. Furthermore, it should be understood that the techniques described herein allow the owner to update access control list 116, which defines access controls for lock device 102, without interacting with the lock device 102 whose access controls are being modified. Although blocks 402-416 are described in a relatively serial manner, it should be understood that various blocks of procedure 400 can be implemented in parallel in some embodiments. Referring now to Figure 5, in use, the access control system 100 can execute a procedure 500 to control a lock device 102 using a guest device 108. It should be understood that the particular blocks of procedure 500 are illustrated by way of example, and such blocks may be combined or split, added or removed, and / or reordered in whole or in part depending on the particular implementation, unless otherwise stated. The illustrative procedure 500 begins with block 502, in which the cloud server 106 determines whether a guest is requesting access control through a particular lock device 102. For example, in some implementations, the guest may request access control over the lock device 102 through application 114 on the guest device 108.In particular, in some embodiments, application 114 may include a graphical user interface that identifies each of the lock devices 102 for which the guest has access control permissions. In some embodiments, application 114 may identify those lock devices 102 for which the guest has ownership and therefore has owner-level access control permissions, in addition to the lock devices 102 for which the guest has guest-level access permissions. Depending on the specific embodiment, application 114 may or may not graphically distinguish between lock devices 102 with owner-level permissions and those with guest-level permissions. After identifying the specific lock device 102 for which access control is desired, in block 504, the guest device 108 requests a conditional bearer cryptographic token from the cloud server 106. In block 506, the cloud server 106 determines whether the guest using the guest device 108 is authorized to control the lock device 102 based on the access control list 116 stored on the cloud server 106. For example, as described above, the guest may be required to securely log in to the cloud server 106 or associated cloud service through a security domain separate from token-based security to verify the guest's identity.Furthermore, in the illustrative embodiment, cloud server 106 compares the guest's identity (for example, the guest UUID generated during secure login) against access control list 116 to confirm that the guest ID is associated with the lock device 102 that the guest wishes to access or control. If the guest's identity cannot be verified via secure login and / or the guest ID is not associated with controlling lock device 102 in access control list 116, access control system 100 performs one or more error-handling procedures in block 508. For example, in some embodiments, cloud server 106 drops its communication connection with guest device 108, alerts the owner of the error, and / or logs the error to an audit file.In addition, application 114 can alert the user of guest device 108 of the error. However, it should be understood that access control system 100 may, additionally or alternatively, perform other appropriate error handling procedures. Returning to block 506, if cloud server 106 determines that the guest is authorized to control lock device 102, procedure 500 advances to block 510, in which cloud server 106 generates a conditional bearer cryptographic token and transmits the generated token to guest device 108. In particular, in block 512, cloud server 106 generates a conditional bearer cryptographic token that includes a time-based condition, which defines a time limit for controlling lock device 102, and a permissions-related condition, which defines a permission level for the token holder, as described herein.The cloud server 106 retrieves the base bearer cryptographic token associated with the lock device 102 (see block 316 in Figure 3) and generates a conditional bearer cryptographic token based on that base bearer cryptographic token. In other embodiments, the cloud server 106 may additionally or alternatively include other conditions. For example, in some embodiments, the generated conditional bearer cryptographic token may include a location-based condition that defines a physical location, region, boundary, and / or radius within which the token is valid (e.g., for mobile lock devices 102 such as bicycle locks). As described above, the bearer cryptographic tokens described herein may include, or be implemented as, macaroons. A macaroon is a data structure that may have conditions attached to it, for example, to limit a user's temporary access and privilege level to a lock device 102. When lock device 102 is paired with owner device 104 (for example, during a one-time action unless a factory reset is performed to clear the data on lock device 102), lock device 102 may generate a macaroon that is transmitted to owner device 104 and forwarded to the cloud server 106 (see blocks 314, 316 in Figure 3).The macaroon can consist of a security key and conditions associated with a macaroon type (e.g., owner, min / administrator, and user / guest) and a timestamp indicating the macaroon's creation time. Additionally, in some implementations, the macaroon may include a condition associated with a macaroon function (e.g., that the macaroon is intended to perform a specific function). The security key can be based, for example, on the SPAKE key generated during pairing between lock device 102 and owner device 104. In other implementations, a different key suitable for the macaroon can be used. The allowed values ​​for the time-based condition can vary depending on the specific implementation. For example, in some implementations, the time-based condition can allow time limits / expiration of one hour, twenty-four hours, thirty days, or absolute / no expiration.In other embodiments, any suitable time limit may be used. It should be understood that, in the illustrative embodiment, the time limits define the amount of time that can elapse from the generation of the macaroon (for example, defined by a timestamp on the macaroon) before the macaroon is considered to have expired. In some embodiments, the base macaroon, base, can be generated according to base = {base_caveats | base_tag}, where base_caveats is a concatenated string of the base macaroon conditions, base_tag = HMAC(key, base_caveats), and HMAC is a message authentication code for base_caveats, calculated using a hash function, with key as the cryptographic hash key. As stated above, it is understood that any suitable key can be used for generating the base macaroon. Furthermore, as described in the present invention, a macaroon can also be derived from the base macaroon (e.g., for transmission to a guest device 108) by thereby reducing the permissions of the base macaroon (e.g., by also including time-limiting and / or permission-limiting conditions).In particular, a derived macaroon, guest, can be generated according to guest = HMAC(base_tag, guest_caveats) = HMAC(HMAC(key, base_caveats), guest_caveats), where guest_caveats is a concatenated string of additional conditions that define the guest's access control permissions. It should also be understood that macaroons can incorporate additional conditions associated with a particular session and / or other relevant information. Referring again to Figure 5, in block 514, guest device 108 establishes a secure communication session with lock device 102, and in block 516, guest device 108 securely transmits a request to control lock device 102 that includes the conditional bearer cryptographic token to lock device 102. In block 518, lock device 102 authenticates the access control request based on the received conditional bearer cryptographic token, the base bearer cryptographic token stored in lock device 102 (see block 316 in Figure 3), and the real-time clock of lock device 102.Specifically, in block 520, lock device 102 compares the conditional bearer cryptographic token with the base bearer cryptographic token to determine whether the conditional bearer cryptographic token is associated with the base bearer cryptographic token. It should be understood that the tokens can be compared directly or indirectly depending on the particular implementation. For example, in the illustrative implementation, lock device 102 determines whether the conditional bearer cryptographic token was obtained from the base bearer cryptographic token using a suitable technique or algorithm (e.g., using the appropriate keys and the HMAC as described above).Additionally, in block 522, lock device 102 compares the time-based condition with the real-time clock of lock device 102 to determine if the current time is within the time limit defined by the time-based condition. If the conditional bearer cryptographic token is not properly associated with the base bearer cryptographic token, or if the current time is outside the time period for time-based condition-authorized control, for example, authentication fails and guest device 108 is determined not to be authorized to control lock device 102. If lock device 102 determines, in block 524, that access control is not authorized, access control system 100 performs one or more error-handling procedures in block 526. For example, access control system 100 might handle the error in a manner similar to that described above with reference to block 508.In particular, the lock device 102 can drop its communication connection with the guest device 108 and / or log the error in an audit file that can be retrieved later (for example, by an owner device 104). Additionally, application 114 can alert the user of guest device 108 to the error. However, it should be understood that the access control system 100 may, additionally or alternatively, perform other appropriate error handling procedures. It should also be understood that, in some embodiments, the access control system 100 can perform an error handling procedure if a guest token is presented and the real-time clock of the lock device 102 has not been set (for example, due to a power reset). To do so, in some embodiments, the access control system 100 can perform one or more of the techniques described in reference to US Patent 15 / 656,678 filed on July 21, 2017. However, if access control is authorized, procedure 500 proceeds to block 528, where guest device 108 can transmit a command to control a function of lock device 102. Specifically, in some embodiments, guest device 108 can transmit a command to lock device 102 to unlock a locking mechanism. In other embodiments, however, guest device 108 can transmit a command to perform any appropriate function, depending on the type of access control device being controlled. In block 530, lock device 102 responds to the command. For example, lock device 102 can perform the requested function in response to receiving the command (e.g., unlocking a locking mechanism).Furthermore, in block 532, in some embodiments, the lock device 102 can transmit a status message to the guest device 108 based on the success or failure of the requested function. For example, in the illustrative embodiment, if the guest has delayed issuing a command such that the time limit defined by the time-based condition is no longer met, the access control attempt will be denied by the lock device 102. It should be understood that the owner can use an owner device 104 to retrieve a contextual bearer cryptographic token at the owner level to access an owner lock device 102 in a manner similar to that described above regarding a guest obtaining a token. However, in some embodiments, the owner token generated by the cloud server 106 does not include a time-based condition or may be less time-bound than the guest token. In other embodiments, the owner can retrieve and use the underlying bearer cryptographic token to access the lock device 102. In the illustrative embodiment, however, the owner device 104 does not perpetually store the underlying bearer cryptographic token, as doing so could pose a security risk to the system. Although blocks 502-532 are described in a relatively serial manner, it should be understood that several blocks of procedure 500 can be implemented in parallel in some embodiments.

Claims

1. A procedure comprising: determining, by a server (106), whether a guest associated with a guest device (108) is authorized to control an access control device (102) based on an access control list (116) stored on the server (106), wherein the access control device (102) is a lock device (102); generating, by the server (106), a conditional cryptographic bearer token from a base cryptographic bearer token in response to a determination that the guest is authorized to control the access control device (102), wherein the base cryptographic bearer token includes a base set of restrictions or conditions and a message authentication code of the base conditions, computed by a hash function using a first cryptographic hash key,where the conditional bearer cryptographic token includes additional conditions attached to the base bearer cryptographic token to limit permissions granted to the guest and a time-based condition, which defines a time limit for the access control device (102) control, and where the server (106) employs a second cryptographic hash key to apply a hash function to the additional conditions to the base bearer cryptographic token to generate the conditional bearer cryptographic token; transmitting, by the server (106), the conditional bearer cryptographic token to the guest device (108) in response to the generation of the conditional bearer cryptographic token; transmitting, by the guest device (108) and in response to the receipt of the conditional bearer cryptographic token from the server (106),1. A request to control the access control device (102) to the access control device (102), wherein the request includes the conditional bearer cryptographic token; and authenticating, by the access control device (102), the request based on the received conditional bearer cryptographic token, the base bearer cryptographic token stored in the access control device (102), and a real-time clock of the access control device (102).

2. The method according to claim 1, further comprising requesting, by the guest device (108),the conditional bearer cryptographic token from the server (106); and wherein determining whether the guest is authorized to control the access control device (102) comprises determining whether the guest is authorized to control the access control device (102) in response to the server's (106) receipt of the conditional bearer cryptographic token request.

3. The method of claim 1, wherein authenticating the request comprises: determining whether the conditional bearer cryptographic token was derived from the base bearer cryptographic token; and comparing the time-based condition with the real-time clock of the access control device (102) to determine whether the current time is within the time limit.

4. The method of claim 1, further comprising: transmitting, by the guest device (108),a command to control a function of the access control device (102) in response to successful authentication of the request by the access control device (102); and to perform, by the access control device (102), the function based on the command.

5. The method of claim 1, wherein the access control list (116) identifies one or more access control devices (102) and guest access control permissions for each of the one or more access control devices (102); and wherein the access control list (116) can be modified by an owner device (104) authenticated through a separate security domain.

6. The method of claim 5, further comprising: verifying, by the server (106), an owner identifier associated with the owner device (104) through the separate security domain; determining, by the server (106),a guest access control permission corresponding to one or more access control devices (102) that is to be revoked; and updating, by the server (106), the access control list (116) to revoke the guest access control permission; wherein the revocation of the guest access control permission prevents the server (106) from subsequently issuing a conditional bearer cryptographic token to a corresponding guest device (108) to control a corresponding access control device (102).

7. The method according to claim 5, further comprising: verifying, by the server (106), an owner identifier associated with the owner device (104) through the separate security domain; transmitting, by the server (106) to a target guest device (108) associated with a target guest, an invitation to control the access control device (102); verifying,by the server (106), a guest identifier of the target guest through the separate security domain; and updating, by the server (106), the access control list (116) to indicate that the target guest is authorized to control the access control device (102) in a time-limited manner and with respect to permissions in response to successful verification of the guest identifier.

8. The method, according to claim 5,further comprising: registering an owner of the access control device (102) with the server (106) via the separate security domain; providing a programming code for the access control device (102) to the owner's device (104); transmitting the cryptographic base-bearer token generated by the access control device (102) from the owner's device (104) to the server (116); and updating the access control list (116) to identify the owner's ownership of the access control device (102).

9. The method of claim 8, wherein the cryptographic base-bearer token stored in the access control device (102) is the cryptographic base-bearer token generated by the access control device (102) and transmitted to the server (106).

10. The method of claim 1,wherein the locking device (102) comprises at least one bolt or latch.

11. Access control system, comprising: a server (106), which includes a first processor (202) and a first memory (206) comprising a first plurality of instructions (208) stored therein which, in response to execution by the first processor (202), cause the server (106) to (i) determine whether a guest associated with a guest device (108) is authorized to control a locking device (102) based on an access control list (116) stored on the server (106); (ii) generate a conditional bearer cryptographic token from a base bearer cryptographic token in response to the determination that the guest is authorized to control the locking device (102),where the base cryptographic bearer token includes a base set of restrictions or conditions and a message authentication code of the base conditions, calculated by a hash function using a first cryptographic hash key, where the conditional cryptographic bearer token includes additional conditions added to the base cryptographic bearer token to limit the permissions granted to the guest and a time-based condition, which defines a time limit for controlling the lock device (102),and wherein the server (106) employs a second cryptographic hash key to apply a hash function to the additional conditions to the base bearer cryptographic token to generate the conditional bearer cryptographic token; and (iii) transmits the conditional bearer cryptographic token to the guest device (108) in response to the generation of the conditional bearer cryptographic token; a guest device (108) including a second processor (202) and a second memory (206) comprising a second plurality of instructions (208) stored therein which, in response to execution by the second processor (202),causes the guest device (108) (i) to receive the conditional bearer cryptographic token from the server (106) and (ii) to transmit a request to control the lock device (102) to the lock device (102) in response to the receipt of the conditional bearer cryptographic token, wherein the request includes the conditional bearer cryptographic token; and the lock device (102) includes a locking mechanism for controlling access through a step, a third processor (202), and a third memory (206) comprising a third plurality of instructions (208) stored therein which, in response to their execution by the third processor (202), cause the lock device (102) to authenticate the request based on the received conditional bearer cryptographic token,the base cryptographic bearer token stored in the lock device (102) and a real-time clock of the lock device (102).

12. The access control system according to claim 11, wherein authenticating the request comprises: determining whether the conditional cryptographic bearer token has been derived from the base cryptographic bearer token; and comparing the time-based condition with the real-time clock of the lock device (102) to determine whether the current time is within the time limit.

13. The access control system according to claim 12,wherein the access control list (116) identifies one or more locking devices and guest access control permissions for each of the one or more locking devices (102); and wherein the access control list (116) can be modified by an owner device (104) authenticated through a separate security domain.

14. The access control system according to claim 13, wherein the second plurality of instructions (208) further causes the guest device (108) to transmit a command to unlock the locking mechanism of the locking device (102) in response to successful authentication of the request by the locking device; and wherein the third plurality of instructions (208) further causes the locking device (102) to unlock the locking mechanism in response to the command.

15. The access control system according to claim 11,wherein the locking mechanism comprises at least one bolt or latch.

Images