CN117461287A

CN117461287A - Establishing a secure bluetooth connection with an internet of things device such as an electronic lock

Info

Publication number: CN117461287A
Application number: CN202280041409.0A
Authority: CN
Inventors: D·伊曼纽尔
Original assignee: Asa Abloy American Housing Inc
Current assignee: Asa Abloy American Housing Inc
Priority date: 2021-04-15
Filing date: 2022-04-15
Publication date: 2024-01-26

Abstract

Systems and methods for managing secure connections between a mobile device and an internet of things device (such as an electronic lock) are disclosed. In some instances, a mutual authentication process is performed and public keys are exchanged. Once the keys are exchanged, subsequent communications between the devices may be encrypted using a shared key that was generated using the exchanged keys.

Description

Establishing a secure bluetooth connection with an internet of things device such as an electronic lock

Cross Reference to Related Applications

The present application was filed on day 15 of 2022 as PCT international patent application claiming priority and appropriateness of each of the following applications: U.S. provisional patent application Ser. No. 63/175,360, filed 4/15 at 2021; U.S. provisional patent application Ser. No.63/241,804, filed on 8/9/2021; and U.S. provisional patent application No.63/275,550, filed on 11/4 of 2021, the disclosures of each of which are incorporated herein by reference in their entirety.

Technical Field

The present invention relates to internet of things (IoT) devices, and more particularly, to establishing and managing secure connections between computing devices, such as mobile devices, and IoT devices, such as electronic locks.

Background

Many internet of things devices use bluetooth to communicate with mobile devices such as smartphones. The bluetooth communication connection may be used for device setup or for the purpose of activating such devices. Typically, the setting is a one-time process for the user, especially in the context of home automation equipment.

Electronic locks are increasingly integrated into home automation systems in single-home and multi-home environments. Particularly in a multi-home environment, there may be a large number of mobile devices that will be granted access to virtually such an electronic lock (e.g., on the next back door of an apartment building). Additionally, in some cases, such as for homes that are available via short term leases (e.g., via AirBNB, VRBO, or other vacation leasing organizations), it may be desirable to provide short range credentials to the guest user.

When bluetooth is used for the connection between the electronic lock and the mobile device, typically the electronic lock will act as a server device for the bluetooth connection and the mobile device will act as a client device. Thus, the electronic lock may need to store a long-term binding key that maintains a secure and authenticated communication channel between the lock and the mobile device.

This results in some significant drawbacks, in which a large number of users may be required to connect to the electronic lock, or binding changes between the mobile device and the electronic lock occur frequently. In particular, electronic locks may have a limit on the number of long-term adhesive keys that may be stored. This limits the number of devices that can be combined and paired with the lock. Additionally, in some cases (e.g., in the instance of a mobile device operating using iOS), the re-pairing or re-binding process requires the user to manually remove the pairing before the re-pairing can be performed.

Disclosure of Invention

Generally, the present disclosure relates to management of secure connections between mobile devices and internet of things devices (such as electronic locks). In some instances, a mutual authentication process is performed and public keys are exchanged. Once the keys are exchanged, subsequent communications between the devices can be encrypted using the exchanged keys, thereby avoiding the need to bind the two devices.

In a first aspect, a method of establishing secure communications with a mobile device at an electronic lock is disclosed. The method includes establishing a communication connection with a mobile device via a short range wireless communication protocol. The method also includes performing at least a portion of a mutual authentication process in which the electronic lock is authenticated to the mobile device and the mobile device is authenticated to the electronic lock. The method includes performing a key generation process to generate an encryption key and a decryption key at the electronic lock. The method also includes performing an encrypted communication with the mobile device using the generated encryption key and decryption key, the encrypted communication occurring using a short-range wireless communication protocol.

In a second aspect, an electronic lock includes a programmable circuit and a short range wireless communication interface communicatively coupled to the programmable circuit. The lock further includes a memory storing instructions that, when executed, cause the programmable circuitry to: establishing a communication connection with the mobile device via the short-range wireless communication interface through a short-range wireless communication protocol; performing at least a portion of a mutual authentication process in which the electronic lock is authenticated to the mobile device and the mobile device is authenticated to the electronic lock; performing a key generation process with the mobile device to generate an encryption key and a decryption key at the electronic lock; and performing an encrypted communication with the mobile device using the generated encryption key and decryption key, the encrypted communication occurring via the short range wireless communication interface using the short range wireless communication protocol via the unbound connection.

In a third aspect, a method of establishing secure communications between a mobile device and an electronic lock is disclosed. The method includes establishing a communication connection between the electronic lock and the mobile device via a short range wireless communication protocol. The method also includes performing a mutual authentication procedure in which the electronic lock is authenticated to the mobile device and the mobile device is authenticated to the electronic lock. The method includes performing a key generation process, the key generation process including: generating a lock salt, a lock public key and a lock private key at the electronic lock, wherein the lock public key and the lock private key form a lock public key-private key pair; generating, at the mobile device, a device salt, a device public key, and a device private key, the device public key and the device private key forming a device public-private key pair; generating a platform signature at the platform cloud, wherein the platform signature is a platform digest signed by a platform private key, and the platform digest is formed by equipment salt and an equipment public key; generating a lock signature at the electronic lock, wherein the lock signature is a lock abstract signed by a lock private key, and the lock abstract is formed by lock salt and a lock public key; verifying the platform signature at the electronic lock using the platform public key, and verifying the lock signature at the platform cloud using the lock public key; generating a lock encryption key and a lock decryption key at the electronic lock based on verifying the platform signature at the electronic lock; and generating, at the mobile device, a mobile device encryption key and a mobile device decryption key based on verifying the lock signature at the platform cloud. The method also includes performing an encrypted communication between the mobile device and the electronic lock using the mobile device encryption key, the mobile device decryption key, the lock encryption key, and the lock decryption key, the encrypted communication occurring via the unbound connection using a short-range wireless communication protocol.

Drawings

The following drawings illustrate specific embodiments of the disclosure and therefore do not limit the scope of the disclosure. The drawings are not to scale and are intended to be used in conjunction with the explanations in the following detailed description. Embodiments of the present disclosure will hereinafter be described in conjunction with the appended drawings, wherein like numerals denote like elements.

FIG. 1 illustrates an environment in which aspects of the present disclosure may be implemented.

Fig. 2 shows a side view of a portion of the electronic lock as seen in the environment of fig. 1.

Fig. 3 shows a rear perspective view of a portion of the electronic lock as seen in the environment of fig. 1.

Fig. 4 shows a front perspective view of a portion of the electronic lock as seen in the environment of fig. 1.

Fig. 5 shows a schematic representation of an electronic lock seen in the environment of fig. 1.

Fig. 6 shows a schematic representation of a mobile device as seen in the environment of fig. 1.

Fig. 7 illustrates a flow chart of a method of managing a secure connection between a mobile device and an electronic lock in accordance with aspects of the present disclosure.

FIG. 8 illustrates a flowchart of a method of disabling a user account previously registered for use with an electronic lock, according to an example embodiment.

Fig. 9 shows a schematic diagram of a certificate deployed to a user account, a mobile device, and an electronic lock for mutual authentication, according to an example embodiment.

Fig. 10 is a message flow diagram depicting a first portion of a secure communication procedure including mutual authentication, in accordance with an example embodiment.

Fig. 11 is a message flow diagram depicting a second portion of a secure communication procedure including mutual authentication, according to an example embodiment.

Fig. 12 is a message flow diagram depicting a third portion of a secure communication procedure including mutual authentication, in accordance with an example embodiment.

Fig. 13 is a message flow diagram depicting a third portion of a secure communication procedure including mutual authentication, in accordance with another example embodiment.

Fig. 14 is a message flow diagram depicting a subsequent message flow after mutual authentication and key exchange between a mobile device and an electronic lock, in accordance with an exemplary embodiment.

Detailed Description

Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. References to various embodiments do not limit the scope of the invention, which is limited only by the scope of the appended claims. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.

As briefly described above, embodiments of the present invention relate to management of secure connections between mobile devices and internet of things devices (such as electronic locks). In some cases, a binding process may be performed to establish a trusted connection between devices. A mutual authentication procedure is performed and the public key is exchanged over the binding connection. Once the keys are exchanged, the binding connection may be terminated. Subsequent communications between devices may be encrypted using the exchanged keys, avoiding the need to maintain a binding between the two devices.

In accordance with the present disclosure, the general method described herein allows avoiding a binding procedure between two devices communicating over bluetooth, or bluetooth pairing using long-term keys in a temporary manner. The long-term binding key may be used for the purpose of temporarily exchanging other keys that may be used to encrypt and secure otherwise unsecured communication paths. The unsecure communication path does not use the bluetooth LE secure connection mechanism and is therefore not limited in terms of the number of keys or the manner of pairing. Thus, the methods described herein may be particularly applicable in contexts where a large number of users may wish to connect to a single device. One such example would be an electronic lock (e.g., an apartment building or a public door of an apartment building) that is presented in a multi-family environment. In such a case, the number of users desiring to be granted access to operate the electronic lock may exceed the number of binding keys available for establishment at the electronic lock (i.e., the number set by the particular bluetooth protocol and/or chipset). The use of alternative key arrangements allows multiple users to use the same key or does not require a separate key stored within the bluetooth chipset itself as part of the binding implementation.

FIG. 1 illustrates an environment 10 in which aspects of the present disclosure may be implemented. A door 14 including an electronic lock 100 (also referred to as a wireless electronic lock) is installed at a house.

The administrative user 12 is a master user or authorizer, such as an owner or tenant of a house installed with a door 14 that includes an electronic lock 100. The administrative user 12 has a mobile device (referred to herein as the administrative mobile device 200) such as a smart phone or tablet computer with wireless communication capabilities. The administrator mobile device 200 is capable of communicating 22 with the server 300, communicating 20 with the electronic lock 100, and communicating 26 with a telephone or other mobile device of the guest user 18 (referred to herein as the guest mobile device 400).

Guest user 18 is a person who manages at least a subset of the actions (e.g., locking, unlocking, changing settings) that user 12 may wish to grant access to perform in association with electronic lock 100. In some examples, guest user 18 may be a short-time guest, such as a vacation rental user. Guest user 18 may also be a long-term user who may not be given administrative access rights to electronic lock 100. Administrative user 12 may wish to allow guest user 18 to pair guest mobile device 400 with electronic lock 100 to enable guest user 18 to perform electronic lock actions via guest mobile device 400. Administrative user 12 may also wish to allow guest user 18 to pair guest mobile device 400 with electronic lock 100 without requiring administrator mobile device 200 to be within wireless communication range of electronic lock 100 and without requiring guest user 18 to actuate a pairing button of electronic lock 100. The guest mobile device 400 is capable of communicating 28 with the server 300, 30 with the electronic lock 100, and 26 with the administrator mobile device 200.

In some further examples, administrative user 12 or guest user 18 may include an installer of the electronic lock, e.g., a constructor or installer at a multi-user building, that may wish to connect to electronic lock 100 to perform an installation process, such as assigning a location to the electronic lock, performing an over-the-air update process with respect to the electronic lock, or other type of action. In this case, the installer (who is either the administrative user 12 or the guest user 18) may use the mobile device 200, 400 to initiate communication with the electronic lock to perform the installation process. As with other cases, the installer is a user who typically does not wish to maintain the mating key in a limited memory location of the electronic lock.

Server 300 may be, for example, a physical server or a virtual server hosted in cloud storage environment 16. In some embodiments, the electronic lock 100 is also capable of communicating 24 with the server 300. Such communication may optionally occur via one or more wireless communication protocols, such as Wi-Fi (IEEE 802.11), short-range wireless communication to Wi-Fi bridges, or other connection mechanisms. According to an embodiment, the server 300 generally creates and stores a management user account associated with the electronic lock 100, stores a pairing password for the electronic lock, stores a guest user account associated with the electronic lock, and in some examples, provides the pairing password to the guest mobile device 400 when the guest user account is created. According to one aspect, when the pairing password is successfully entered using the keypad of the electronic lock 100, the electronic lock 100 may enter a pairing mode that enables the electronic lock 100 to be paired with the guest mobile device 400 via a bluetooth connection. As described above, this "pairing" process may be performed by temporarily using an existing bluetooth pairing process implemented in a typical bluetooth chipset, or by avoiding the use of the pairing process entirely and separately managing encryption keys for connections between devices.

Fig. 2-4 illustrate an electronic lock 100 mounted at a door 14 according to one example of the present disclosure. Door 14 has an inner side 104 and an outer side 106. Electronic lock 100 includes an inner assembly 108, an outer assembly 110, and a latch assembly 112. The latch assembly 112 is shown as including a latch 114 that is movable between an extended position (locked) and a retracted position (unlocked, as shown in fig. 2-4). Specifically, the latch 114 is configured to slide longitudinally, and when the latch 114 is retracted, the door 14 is in an unlocked state. When the latch 114 is extended, the latch 114 protrudes from the door 14 into a door jamb (not shown) to place the door in a locked condition.

In some examples, the inner assembly 108 is mounted to the inner side 104 of the door 14 and the outer assembly 110 is mounted to the outer side 106 of the door 14. Latch assembly 112 is typically mounted at least partially in an aperture formed in door 14. The term "exterior" is used broadly to refer to the area outside of door 14, and "interior" is used broadly to refer to the area inside door 14. For example, for an external access door, the external component 110 may be installed outside the building, while the internal component 108 may be installed inside the building. With the interior door, the external component 110 may be installed inside a building, but outside the room protected by the electronic lock 100, and the internal component 108 may be installed inside a secure room. The electronic lock 100 is suitable for use with interior and exterior doors.

Referring to fig. 3, the internal components 108 may include a processing unit 116 (shown schematically), the processing unit 116 containing electronic circuitry for the electronic lock 100. In some examples, the inner assembly 108 includes a manual rotator 118 that may be used on the inner side 104 of the door 14 to move the latch 114 between the extended and retracted positions. The processing unit 116 is operable to execute a plurality of software instructions (i.e., firmware) that when executed by the processing unit 116 cause the electronic lock 100 to implement methods and otherwise operate and have the functions as described herein. The processing unit 116 may include a device commonly referred to as a processor, such as a Central Processing Unit (CPU), digital Signal Processor (DSP), or other similar device, and may be embodied as a stand-alone unit or as a device shared with components of the electronic lock 100. The processing unit 116 may include a processor communicatively interfaced to a memory for storing software instructions. Alternatively, the electronic lock 100 may also include a separate memory device for storing software instructions that is electrically connected to the processing unit 116 for bi-directional communication of instructions, data, and signals therebetween.

In some examples, the internal component 108 includes a pairing button 119 (shown schematically) that, when actuated, initiates a BLE communication pairing mode. For example, the pairing mode may enable the electronic lock 100 to communicate with mobile devices (e.g., administrator mobile device 200, guest mobile device 400) within wireless communication range to enable the mobile devices to be paired with the electronic lock 100. It will be appreciated that initiating the BLE pairing mode by actuating pairing button 119 may be limited to users having access to the inner side 104 of door 14.

As will be described in further detail below, aspects of the present disclosure enable a user (such as administrative user 12 or guest user 18) to initiate BLE communications with electronic lock 100 from a mobile device, rather than using pairing button 119. In this case, a pairing sequence may be initiated that does not ultimately result in a durable binding pairing between the devices. In some cases, pressing pairing button 119 may cause a persistent pairing arrangement of binding to occur, while initiating a communication link between electronic lock 100 and mobile device 200, 400 using an application installed on the mobile device avoids a persistent pairing arrangement of binding. In other cases, pressing pairing button 119 also avoids using a binding connection to maintain a persistent pairing.

Referring to fig. 4, the external component 110 may include external circuitry communicatively and electrically connected to the processing unit 116. For example, the external component 110 may include a keypad 120 for receiving user input and/or a key slot 122 for receiving a key (not shown). The exterior side 106 of the door 14 may also include a handle 124. In some examples, the external component 110 includes a keypad 120 and does not include a keyway 122. In some examples, the external component 110 includes a keyway 122 instead of the keypad 120. In some examples, the outer assembly 110 includes a key slot 122 and a keypad 120. The valid key may move the latch 114 between the extended and retracted positions when inserted into the keyway 122. When a user enters a valid actuation code into the keypad 120, the latch 114 moves between the extended and retracted positions. In some examples, the external component 110 is electrically connected to the internal component 108. In particular, the keypad 120 is electrically connected to the internal components 108, in particular to the processing unit 116, by means of a cable (not shown) passing through the door 14, for example. When the user enters a valid actuation code identified by the processing unit 116 via the keypad 120, the electric motor is energized to retract the latch 114 of the latch assembly 112, allowing the door 14 to open from the closed position. In particular embodiments, electronic lock 100 may enter a pairing mode when guest user 18 enters a valid pairing password into keypad 120, wherein electronic lock 100 is able to communicate and pair with guest mobile device 400 when the guest mobile device is within wireless communication range of electronic lock 100. Further, as described below, the electrical connection between the external component 110 and the internal component 108 allows the processing unit 116 to communicate with other features included in the external component 110.

Keypad 120 may be any of a variety of different types of keypads. Keypad 120 may be one of a numeric keypad, an alphanumeric keypad, and/or an alphanumeric keypad. The keyboard 120 may have a plurality of characters displayed thereon. For example, the keypad 120 may include a plurality of buttons 126 that may be mechanically actuated (e.g., physically pressed) by a user. In some examples, keypad 120 includes a touch interface 128, such as a touch screen or touch keypad, for receiving user input. The touch interface 128 is configured to detect a user's "push button" by contact without requiring pressure or mechanical actuation. An example of a touch interface is described in U.S. patent No. 9,424,700, entitled "ELECTRONIC LOCK HAVING USAGE AND WEAR LEVELING OF ATOUCH SURFACE THROUGH RANDOMIZED CODE ENTRY," which is incorporated by reference herein in its entirety.

In alternative embodiments, one or more other types of user interface devices may be incorporated into the electronic lock 100. For example, in an exemplary embodiment, the external component 110 may include a biometric interface (e.g., a fingerprint sensor, a retinal scanner, or a camera including facial recognition) or an audio interface through which voice recognition may be used to actuate the lock. Still further, other touch interfaces may be implemented, for example, wherein a single touch may be used to actuate a lock without requiring entry of a specified actuation code.

Fig. 5 is a schematic view of an electronic lock 100 mounted to a door 14. An inner assembly 108, an outer assembly 110, and a latch assembly 112 are shown.

The external component 110 is shown to include a keyboard 120 and an optional external antenna 130 that may be used to communicate with a remote device. Further, the external component 110 may include one or more sensors 131, such as cameras, proximity sensors, or other mechanisms that may sense conditions external to the door 14. In response to such sensed conditions, electronic lock 100 may send a notification to server 300, administrator mobile device 200, or guest mobile device 400 that includes information associated with the sensed event (e.g., time and description of the sensed event, or remote feed of sensor data obtained via the sensor).

The external antenna 130 can be used in conjunction with the internal antenna 134 so that the processing unit 116 can determine where the mobile device is located. Only mobile devices paired with the electronic lock 100 and determined to be located outside of the door 14 (e.g., the administrator mobile device 200 or the guest mobile device 400) are able to actuate (unlock or lock) the door. This prevents an unauthorized user from being located outside of the door 14 of the electronic lock 100 and utilizing an authorized mobile device that may be located inside the door even if the authorized mobile device is not used to actuate the door. However, such a feature is not necessary, but may add additional security. In alternative arrangements, the electronic lock 100 may only be actuated from the keypad 120 (via entry of a valid actuation code) or from an application installed on a mobile device (e.g., the administrator mobile device 200 or the guest mobile device 400). In such an arrangement, the external antenna 130 may be completely eliminated because a touch alone at the exterior of the door 14 cannot actuate the lock.

As described above, the internal components 108 include the processing unit 116. The internal assembly 108 may also include a motor 132 and an optional internal antenna 134.

As shown, the processing unit 116 includes at least one processor 136 communicatively connected to a secure chip 137, a memory 138, various wireless communication interfaces (e.g., including a Wi-Fi interface 139 and/or a bluetooth interface 140), and a battery 142. The processing unit 116 is located within the inner assembly 108 and is capable of operating the electronic lock 100, for example, by actuating the motor 132 to actuate the latch 114.

In some examples, the processor 136 may process signals received from various devices to determine whether the electronic lock 100 should be actuated. Such processing may be based on a set of preprogrammed instructions (i.e., firmware) stored in memory 138. In some embodiments, the processing unit 116 may include a plurality of processors 136, including one or more general purpose or special purpose instruction processors. In some examples, the processing unit 116 is configured to capture keypad input events from a user and store the keypad input events in the memory 138. In other examples, the processor 136 receives signals from the external antenna 130, the internal antenna 134, or the motion sensor 135 (e.g., vibration sensor, gyroscope, accelerometer, motion/position sensor, or a combination thereof) and may verify the received signals in order to actuate the lock 100. In other examples, the processor 136 receives a signal from the bluetooth interface 140 to determine whether to actuate the electronic lock 100.

In some embodiments, the processing unit 116 includes a secure chip 137 communicatively interconnected with one or more instances of the processor 136. The security chip 137 may, for example, generate and store encryption information that may be used to generate credentials that may be used to authenticate the electronic lock 100 with a remote system such as the server 300 or a mobile device (e.g., the administrator mobile device 200 or the guest mobile device 400). In some embodiments, the secure chip 137 includes a write-once function, wherein a portion of the memory of the secure chip 137 may be written to only once and then locked. Such memory may be used, for example, to store encrypted information derived from characteristics of the electronic lock 100 or its communication channel with the server 300 or one or more mobile devices 200, 400. Thus, once written, such encrypted information may be used in a credential generation process that ensures that if any of the characteristics reflected in the encrypted information change, the credential generated by the security chip 137 will become invalid, thereby disabling the electronic lock 100 from performing various functions, such as communicating with the server 300 or mobile device 200, 400, or not operating at all, in some cases.

In some embodiments, the security chip 137 may be configured to generate a pairing password that, when entered using the keypad 120 of the electronic lock 100, triggers a BLE pairing mode of the electronic lock 100 that enables the electronic lock 100 to be paired with a nearby mobile device (e.g., a guest mobile device 400 on which an electronic lock application associated with the electronic lock 100 is operating). In some examples, the pairing passcode is provided to the administrative user 12 upon initial setup/activation of the electronic lock 100 (e.g., via an electronic lock application associated with the electronic lock 100 operating on the administrative mobile device 200). In some examples, the pairing password is a random value. In some examples, administrative user 12 may be enabled to change the pairing password by setting their own code or by requesting a random value generated by an electronic lock application operating on administrative mobile device 200. In some examples, the length of the pairing password is variable. According to one aspect, to increase security, the pairing password may be a limited use password. For example, the pairing password may be limited to a single use, or may be active for a duration preset or governed by the user selection. In further examples, the number of pairing passwords may correspond to a setting that may instruct the electronic lock 100 to perform one or more of: disabling the pairing password after the pairing password has been used; maintaining the enabling of the pairing password after use; or reset the pairing password to a new random value after it is used.

Memory 138 may include any of a variety of memory devices, such as using various types of computer-readable or computer storage media. A computer storage medium or computer readable medium may be any medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. By way of example, computer storage media may include Dynamic Random Access Memory (DRAM) or variations thereof, solid state memory, read Only Memory (ROM), electrically erasable programmable ROM, and other types of devices and/or articles of manufacture that store data. Computer storage media typically includes at least one or more tangible media or devices. In some examples, a computer storage medium may include an embodiment that includes entirely non-transitory components.

As described above, the processing unit 116 may include one or more wireless interfaces, such as a Wi-Fi interface 139 and/or a bluetooth interface 140. Other RF circuitry may also be included. In the example shown, the interfaces 139, 140 are capable of communicating using at least one wireless communication protocol. In some examples, the processing unit 116 may communicate with a remote device via a Wi-Fi interface 139 or with a local device via a bluetooth interface 140. In some examples, the processing unit 116 may communicate with one or both of the mobile device 200, 400 and the server 300 via a Wi-Fi interface, and may communicate with the mobile device 200, 400 via the bluetooth interface 140 when the mobile device is proximate to the electronic lock 100. In some embodiments, the processing unit 116 is configured to communicate with the mobile device 200, 400 via the bluetooth interface 140, and when the mobile device 200, 400 is beyond the range of bluetooth wireless signals, communications between the mobile device 200, 400 and the electronic lock 100 may be relayed via the server 300 (e.g., via the Wi-Fi interface 139).

Bluetooth interface 140 is an example of a short range wireless interface that is capable of communicating with devices using a short range wireless protocol. Although bluetooth is the example interface and protocol shown, other protocols may be used via one or more additional wireless interfaces. In some examples, electronic lock 100 may communicate wirelessly with an external device via a desired wireless communication protocol. In some examples, the external device may wirelessly control operation of electronic lock 100, such as operation of latch 114. Electronic lock 100 may utilize a wireless protocol including, but not limited to, the IEEE 802.11 standardIEEE 802.15.4 standard (++>And ) IEEE 802.15.1 standard->Cellular network, wireless local area network, near field communication protocol, and/or other network protocols. In some examples, electronic lock 100 may communicate wirelessly with a networked and/or distributed computing system, such as may be present in a cloud computing environment.

In a particular embodiment, the processor 136 will receive a signal from the mobile device 200, 400 via a wireless communication protocol (e.g., BLE) at the bluetooth interface 140 for communicating an intent to actuate the electronic lock 100. As shown in further detail below, the processor 136 may also initiate communication with the server 300 via the Wi-Fi interface 139 (or another wireless interface) to verify attempted actuation of the electronic lock 100, or receive an actuation command to actuate the electronic lock 100. In addition, various other settings may be viewed and/or modified from the server 300 via the Wi-Fi interface 139; in this way, a user of mobile device 200, 400 (e.g., administrative user 12 or guest user 18) may access an account associated with electronic lock 100 to view and modify settings of the lock and then propagate the settings from server 300 to electronic lock 100. In other examples, the processor 136 may communicate with the server 300 via a connection through a mobile device (e.g., mobile devices 200, 400 within range of a short range wireless connection). In alternative embodiments, other types of wireless interfaces may be used; in general, the wireless interface for communicating with the mobile device may operate using a different wireless protocol than the wireless interface for communicating with the server 300.

In a particular example, bluetooth interface 140 includes a Bluetooth Low Energy (BLE) interface. Additionally, in some embodiments, bluetooth interface 140 is associated with a security chip 141, e.g., cryptographic circuitry capable of storing cryptographic information and generating an encryption key that may be used to generate credentials for communicating with other systems (e.g., mobile devices 200, 400). As described further below, the electronic lock 100 may exchange credentials with a mobile device as part of a mutual authentication process for establishing a non-paired secure connection between the electronic lock and the mobile device. Further, as previously described, the bluetooth interface 140 may have a limited number of storage locations for the bound device key information. The unpaired secure connection allows exchanging keys that do not need to be stored in the limited memory location of the bluetooth interface 140.

The internal assembly 108 also includes a battery 142 that powers the electronic lock 100. In one example, battery 142 may be a standard single use (disposable) battery. Alternatively, the battery 142 may be rechargeable. In still further embodiments, the battery 142 is entirely optional, being replaced by an alternative power source (e.g., an AC power connection).

The inner assembly 108 also includes a motor 132 that is capable of actuating the latch 114. In use, the motor 132 receives an actuation command from the processing unit 116 that causes the motor 132 to actuate the latch 114 from the locked position to the unlocked position or from the unlocked position to the locked position. In some examples, the motor 132 actuates the latch 114 to the opposite state. In some examples, the motor 132 receives a designated lock or unlock command, wherein the motor 132 actuates the latch 114 only when the latch 114 is in the correct position. For example, if the door 14 is locked and the motor 132 receives a lock command, no action is taken. If the door 14 is locked and the motor 132 receives an unlock command, the motor 132 actuates the latch 114 to unlock the door 14.

As described above, an optional internal antenna 134 may also be located in the internal component 108. In some examples, the internal antenna 134 is operable with the external antenna 130 to determine the location of the mobile device 200, 400. In some examples, only mobile devices determined to be located on the outside 106 of the door 14 are able to unlock (or lock) the door 14. This prevents an unauthorized user from being located near the electronic lock 100 and utilizing an authorized mobile device that may be located inside the door 14 even if the authorized mobile device is not used to unlock the door 14. In alternative embodiments, the internal antenna 134 may be eliminated entirely, as the electronic lock 100 is actuated only by authorized mobile devices.

Referring generally to fig. 2-5, in an exemplary embodiment, the electronic lock 100 may be used on both an inner door and an outer door. Described below is a non-limiting example of a wireless electronic lockset. It should be noted that the electronic lock 100 may be used on other types of doors, such as garage doors or dog doors, or other types of doors that require an authentication process to unlock (or lock) the door.

In some embodiments, the electronic lock 100 is made of mixed metal and plastic with an engineered cavity to house the electronics and antenna. For example, in some embodiments, the lock utilizes an antenna near the exterior face of the lock, which is designed inside the metal body of the lock itself. The metal body may be designed to meet stringent physical security requirements and also allow the embedded forward antenna to efficiently propagate RF energy.

In still further exemplary embodiments, the electronic lock 100 may include an integrated motion sensor 135. The use of such a motion sensor (e.g., accelerometer, gyroscope, or other location or motion sensor) and the wireless capabilities of the mobile device or electronic device (i.e., key fob) with these capabilities embedded therein may assist in determining additional types of events (e.g., door open or door close events, lock actuation or lock location events, or tap events based on door vibrations). In some cases, the motion event may cause the electronic lock 100 to perform certain processes, for example, to communicatively connect to a mobile device 200, 400 in the vicinity of the electronic lock 100 or to send data to a mobile device 200, 400 in the vicinity of the electronic lock 100.

Of course, in alternative embodiments, other lock actuation sequences may not require the use of the motion sensor 135. For example, if the mobile device 200, 400 is within the effective range of the electronic lock 100 when using a particular wireless protocol (e.g., bluetooth low energy), a connection will be established with the electronic lock 100. Other arrangements using other connection sequences and/or communication protocols are also possible.

Fig. 6 shows a schematic diagram of a mobile device (such as an administrator mobile device 200 and/or guest device 400) that may be used to enable communication with electronic lock 100 in embodiments of the present disclosure. In some embodiments, the mobile device 200, 400 operates to form a bluetooth or BLE connection with a network-enabled security device, such as the electronic lock 100. The mobile device 200, 400 then communicates with the cloud server 300 via Wi-Fi or mobile data connection. Thus, the mobile device 200, 400 may operate to transfer information between the electronic lock 100 and the server 300. The mobile device 200, 400 shown in fig. 6 includes an input device 602, an output device 604, a processor 606, a wireless Wi-Fi interface 608, a wireless bluetooth (e.g., BLE) interface 610, a power supply 612, and a memory 614.

The input device 602 operates to receive input from an external source. Such sources may include input received from a user (e.g., administrative user 12 or guest user 18). Input may be received through a touch screen, stylus, keyboard, or the like.

The output device 604 operates to provide information output from the mobile device 200, 400. For example, the display may output visual information and the speaker may output audio information.

The processor 606 reads data and instructions. The data and instructions may be stored locally, received from an external source, or accessed from a removable medium. The wireless Wi-Fi interface 608 is similar to the Wi-Fi interface 139. The Wi-Fi connection 22, 28 may be established with the server 300. Wireless BLE interface 610 is similar to bluetooth interface 140. A BLE connection 20, 30 may be established with the electronic lock 100. The power supply 612 provides power to the processor 606.

Memory 614 includes software applications 620 and an operating system 622. The memory 614 contains data and instructions that can be used by the processor to implement the various functions of the mobile device 200, 400.

The software applications 620 may include applications that are operable to perform various functions on the mobile devices 200, 400. One such application is an electronic lock application 624. In particular embodiments, when electronic lock application 624 is operating on administrative mobile device 200, electronic lock application 624 may be configured to provide a user interface, set/activate electronic lock 100, generate an administrative user account associated with electronic lock 100, present a random pairing password for electronic lock 100 to administrative user 12 (which may be reset or closed by administrative user 12), and send (e.g., via BLE connection 20 or Wi-Fi connection 22, 24 with electronic lock 100). The pairing password is sent to the electronic lock 100 for storage and stored locally on the administrator mobile device 200 and/or the server 300. In example implementations, while the administrator mobile device 200 may remain paired with the electronic lock 100, in some cases, binding of the guest mobile device 400 to the electronic lock may not be desirable due to the number of guest devices that require lock access, or due to the particular role of the guest (e.g., short-term guest, installer, etc.).

In another embodiment, electronic lock application 624 may provide a selectable "add user" feature that, when selected, enables administrative user 12 to add another user (e.g., guest user 18) to access electronic lock 100, receive administrative user input of electronic contact information (e.g., mobile device phone number, email address, messaging application identifier, social media account identifier) for the guest user. A link is generated that may be shared with guest user 18 that allows guest user 18 to access electronic lock application 624 and create a guest user account associated with administrative user account and electronic lock 100 and send a message including the link to guest mobile device 400 via the received electronic contact information.

In particular embodiments, in response to receiving the link and receiving a selection of the link, electronic lock application 624 may be installed on guest mobile device 400 and used to create a guest user account associated with managing user accounts and electronic lock 100. When the electronic lock application 624 is operating on the guest mobile device 400, the electronic lock application 624 may be configured to determine when the guest mobile device 400 is proximate to the electronic lock 100, determining that the guest mobile device 400 was previously unregistered for use with the electronic lock 100. In the example embodiments described herein, rather than requiring the guest user to perform a pairing process, a mutual authentication process may be performed between the guest mobile device 400 and the electronic lock 100 based on the guest user being previously allowed to access the electronic lock 100 via an account created within the cloud server 300. As described further below, the guest mobile device 400 may establish a secure communication connection with the electronic lock 100 via the exchanged encryption keys via a mutual authentication process without pairing the mobile device 400 with the electronic lock 100. Thus, for some such guest devices, adding and removing the guest device from a pairing relationship with the electronic lock 100 may be simplified and managed entirely via the electronic lock application 624 and the electronic lock 100, regardless of the particular bluetooth implementation on a given guest mobile device 400, and without reserving limited memory locations within the bluetooth circuitry of the electronic lock 100 for long-term binding between the guest mobile device 400 and the electronic lock 100. Further, at the guest mobile device 400 that is not paired with the electronic lock 100 via the BLE connection, the guest mobile device 400 may provide (e.g., display) in a user interface a pairing password and instructions for pairing the guest mobile device 400 with the electronic lock 100. According to an embodiment, when a pairing password is entered using the keypad 120 of the electronic lock 100, the electronic lock 100 may be triggered to enter a bluetooth pairing mode. The electronic lock application 624 may also be configured to determine that the electronic lock 100 is in a bluetooth pairing mode and perform a pairing process with the electronic lock 100 that, when completed, enables the guest user 18 to perform at least a subset of electronic lock actions (e.g., actuate the electronic lock 100, add an access/actuation code) via the electronic lock application 624.

Referring now to fig. 7, an example flow chart of a method 700 of providing wireless communication pairing of a mobile device (such as a guest mobile device 400) with an electronic lock 100 is shown. Such wireless communication pairing may be automatic (e.g., at installation time) or in response to a security password entered by the guest user.

Fig. 7 illustrates a flow chart of a method 700 of managing a secure connection between a mobile device and an electronic lock in accordance with aspects of the present disclosure. Aspects of method 700 may be performed using administrator mobile device 200, while other aspects may be performed using administrator mobile device 200 or guest mobile device 400. According to various embodiments, the method may be performed by avoiding the use of a bluetooth binding procedure altogether, or by temporarily using a bluetooth binding procedure, and then removing the binding arrangement between devices.

In the illustrated example, method 700 includes establishing a secure-bound BLE pairing connection between a mobile device and an internet of things device (such as electronic lock 100) (step 702). The secure BLE connection may be initiated by a user (e.g., administrative user 12) via the administrative mobile device 200. This may be performed, for example, based on initiation from the electronic lock application 624 or pressing the bluetooth pairing button 119 on the electronic lock 100.

The use of secure binding BLE pairing connection may be performed only in some embodiments, for example, where a user (e.g., administrative user 12) intends to connect to only a single electronic lock during a temporary or long-term binding process. However, in some example embodiments, the process may be simplified to avoid full use of the binding connection, for example, in the event that an installer wishes to connect to a series of electronic locks to assign regions/rights to the locks and/or initiate an update to the software of the electronic locks. Instead, in this case, a mobile device (such as administrator mobile device 200 or guest mobile device 400) may simply detect the electronic lock and connect to the lock using an unsecured short-range communication (e.g., bluetooth) connection until a key exchange can be performed, as described below.

In the illustrated example, the method 700 further includes creating an encrypted object for authenticating the mobile device 200 and the electronic lock 100, as well as other mobile devices that may need to be connected to the electronic lock 100 (step 704). Certificates and/or keys, such as public-private key pairs, are used by each user account and device for the purpose of mutually authenticating and protecting communications therebetween. Details regarding the process for mutually authenticating a mobile device and an internet of things device (such as an electronic lock) are described below.

The method 700 further includes establishing a mutual authentication between the mobile device and the electronic lock (step 706). In an example embodiment, establishing the mutual authentication involves exchanging credentials generated based at least in part on a shared secret generated by another trusted device. A method of performing mutual authentication is described below in fig. 10 to 12. In addition, an example method of performing mutual authentication is provided, for example, in PCT publication No. WO 2020/056272, entitled "Authentication of Internet of Things Devices, including Electronic Locks," the disclosure of which is incorporated herein by reference in its entirety.

The method 700 further includes performing a key exchange between the mobile device and the electronic lock (step 708). The key exchange may include an electronic lock and generate a lock public key and a lock private key (lock PuK, lock Prik, respectively), and a cloud account or mobile device generates a device public key and a device private key (device PuK, device Prik, respectively). The electronic lock may send the lock public key to the mobile device and the mobile device may return the device public key. In an example embodiment, the key exchange may include an elliptic curve Diffie-Hellman (ECDH) key exchange to generate a shared encryption key or a shared encryption key set, or some combination thereof. In some examples, the lock and the mobile application will use the exchanged public keys to generate a shared secret key that can be used to encrypt all subsequent communications between the mobile device and the electronic lock over bluetooth.

At this point, the electronic lock 100 and the mobile device have exchanged enough encrypted information to be able to communicate securely over an otherwise unsecured wireless connection. Thus, method 700 may include tearing down the binding connection between the mobile device and the electronic lock (step 710), for example if such binding connection was created in step 702. This may include, for example, unpairing the mobile device and the electronic lock such that the electronic lock will not need to maintain the pairing key within a bluetooth implementation of the electronic lock for the mobile device.

The method 700 further includes performing encrypted communications over the unbound connection (step 712). The encrypted communication may be between the mobile device and the electronic lock, and the shared key may be used to encrypt data to be transmitted over an otherwise unsecured, unbound connection between the device and the lock.

Referring generally to FIG. 7, note that each of steps 702-712 is typically performed by the administrator mobile device 200 during an initial lock setup process; however, not all such steps are required during subsequent communications between the administrator mobile device 200 and the electronic lock 100, and not all such steps are required during communications between the guest mobile device 400 and the electronic lock 100. For example, because the managing mobile device 200 has established a set of encryption keys for encrypted communications with the electronic lock, during a subsequent communication sequence, the managing mobile device 200 may optionally simply use the previously exchanged keys for secure communications (e.g., proceed directly to step 712).

In the case where the guest mobile device 400 is initially connected to the electronic lock 100, it may be necessary to authenticate the guest mobile device to the electronic lock prior to exchanging the encryption key. Thus, although security binding is not required (e.g., using the administrator mobile device 200 in some cases), in some cases an encrypted object may be created (or may have been created) (step 704), the guest mobile device 400 may perform a mutual authentication process with the electronic lock (step 706) and perform a key exchange (step 708). By doing so, such guest mobile device 400 may verify the identity of electronic lock 100 using credentials received from the electronic lock, as described below; similarly, the electronic lock 100 may use the credentials of the guest mobile device 400 to verify the identity of the device without requiring a binding connection. Once the credentials of each device are verified, the public key may be exchanged and a shared key may be generated for encrypting subsequent bluetooth communications (steps 710, 712). During a subsequent communication sequence, the guest mobile device 400 may optionally use the shared key, or alternatively use a previously exchanged key for secure communication (e.g., proceed directly to step 712).

Referring generally to fig. 7, note that some bluetooth implementations have only a limited number of available key storage locations for binding devices that may be used, without regard to restrictions regarding the number of bindable devices. In an exemplary embodiment, a bluetooth solution at electronic lock 100 may only provide up to 16 mating keys. However, using the unbound encrypted communications described herein, the number of mobile devices (administrator mobile device 200 or guest mobile device 400) that can communicate with the electronic lock is not so limited, and thus the method described herein may be advantageous in arrangements with a large number of users that need to connect to a particular lock.

Fig. 8 illustrates a flowchart of a method 800 of disabling a user account previously registered for use with an electronic lock, according to an example embodiment. The method 800 may be performed, for example, for a guest mobile device 400 associated with a guest account that has been disabled for use with the electronic lock 100.

In the example shown, method 800 includes disabling a mobile device account (step 802). Disabling the account may include, for example, receiving an indication from the administrator mobile device 200 that a user should be removed from access to the electronic lock 100 using a particular mobile device (such as the guest mobile device 400) of the other mobile devices capable of actuating the electronic lock. Disabling the mobile device account may also include receiving an indication in the electronic lock application 624 of the administrator mobile device 200 or the guest mobile device 400 that the device (or another device if received in the electronic lock application of the administrator mobile device 200) should be disassociated from the electronic lock 100.

The method 800 also includes deleting the encrypted object (e.g., a public-private key pair generated by the device, and optionally a pairing key generated based on the keys). This may include, for example, if a disabled account occurs at the administrator mobile device 200, sending a message to the device indicating that its access has been disabled. Once the mobile device is within range of the electronic lock 100 (at operation 806), the account identifier may be obtained and account details, such as the associated public-private key pair (if reserved after generation of the shared key), the mobile device identifier, and the shared key, may be deleted from the storage device of the electronic lock 100. A mobile device that comes within range of an electronic lock may be a device associated with a disabled account. In other examples, the mobile device may be a managing mobile device 200 that may store device identifier information and may have the authority to add, delete, or modify user accounts at the electronic lock 100. Until such a mobile device is within range of the electronic lock, the electronic lock may simply retain account information and key information in memory because the mobile device will be deactivated and prevented from communicating with the electronic lock, because it will lack the cryptographic information required for encrypted communications, and will further lack the credentials required for mutual authentication (as applicable credentials are revoked when the account is deactivated). Thus, from the perspective of any particular mobile device (such as the administrator mobile device 200 or the guest mobile device 400), user management may be performed entirely within the cloud account and unnecessary key storage at the electronic lock itself may be avoided, or pairing arrangements manually removed at the mobile device.

Fig. 9 shows a schematic diagram of an arrangement 900 of credentials deployed to a user account, a mobile device, and an electronic lock for mutual authentication, according to an example embodiment.

In the example shown, each of the plurality of electronic locks 100a-n may be deployed at various user premises. Each electronic lock will be issued a unique device certificate 902a-n and a corresponding private key 930a-n. For example, the private key may be provided at the manufacturer prior to distribution and installation. The certificate 902 of each electronic lock may include a unique identifier of the electronic lock that may be used within the overall arrangement 900. The private key 930 associated with the certificate 902 is used during the mutual authentication procedure, for example, to sign a challenge issued by the server 300 via the electronic lock application 624.

The unique device certificate 902 is signed by a device certificate authority certificate 904 of the device certificate authority. The device certificate authority certificate 904 may be securely managed, for example, by the manufacturer of the electronic lock. The device certificate authority certificate 904 is in turn signed by the enterprise root certificate 906. For example, the enterprise root certificate may be a certificate issued by an enterprise such as the manufacturer of electronic lock 100 or a certificate authority affiliated with the manufacturer. In this arrangement, enterprise root certificate 906 corresponds to a self-signed root certificate that may be used on various product lines of a given manufacturer. The device certificate authority certificate 904 may similarly be generated by the device manufacturer or other entity that manages the accounts of users associated with such devices.

In addition, one or more partner platform certificates 910a-n may be maintained within a cloud instance 920 associated with the enterprise. Cloud instance 920 may be part of a virtual environment that forms server 300 described above in fig. 1. Partner platform certificates 910a-n are each associated with a partner platform's private key 940a-n, which private key 940a-n may be used during a mutual authentication process described below (e.g., signing challenges issued by electronic lock 100). Each of partner platform certificates 910 may be signed by a cloud certificate 912 corresponding to the enterprise cloud certificate. Cloud certificate 912 may also be signed by enterprise root certificate 906, and public cloud certificate authority certificate 916 may be provided to each electronic lock for verification, as discussed in further detail below. In general, an electronic lock that receives public cloud certificate authority certificate 916 may be stored at the electronic lock to link the electronic lock to that particular platform and platform certificate.

In short, as shown in fig. 9, two partial certificate chains may be provided to the electronic lock and the cloud instance, respectively, that allow the electronic lock and the user account in the cloud instance to verify each other as legitimate. Thus, the certificate chains for the two partner platforms and for the electronic lock may be verified via the certificate chains as trusted by the corporation.

Referring now to fig. 10-13, a series of message flow diagrams are shown that together form a mutual authentication procedure that may be used in conjunction with the credentials described above to securely authenticate user devices to an electronic lock and vice versa to allow exchange of key information and subsequent encrypted communications between the devices.

In some cases, the message flows of fig. 10-13 include providing a user with access to an electronic lock via a web portal or application. A user may access the electronic lock 100 with their mobile device 200, 400, the mobile device 200, 400 having an application (e.g., electronic lock application 624) installed thereon. A user may log into an account associated with the user in an application, where the account has been given access to a lock. When the application opens, the application initiates a BLE scanning process in the background and identifies the electronic lock.

Fig. 10 is a message flow diagram depicting a first portion 1000 of a secure communication procedure including mutual authentication, in accordance with an example embodiment. The message flow diagram of fig. 10 generally represents a portion of an initial connection and mutual authentication process in which an electronic lock (such as electronic lock 100) authenticates a cloud provider associated with a mobile application (such as electronic lock application 624). Cloud providers may include, for example, a platform cloud 1010 and an enterprise cloud 1020. Platform cloud 1010 and enterprise cloud 1020 may be used to manage credentials and accounts for various user devices and may provide the functionality of server 300 of fig. 1.

The electronic lock application 624 on the mobile device 200, 400 will receive the unique credentials from the cloud account (e.g., from the enterprise cloud 1020 via the platform cloud 1010) and send the unique credentials to the electronic lock 100. Optionally, the electronic lock 100 will verify the certificate chain reflected in the certificate using a certificate authority authorized by the cloud account. In particular, the electronic lock 100 will verify a unique certificate, such as a partner platform certificate, by determining whether the certificate authority certificate is used to sign the partner platform certificate, thereby indicating its legitimacy.

After verifying the certificate chain, the electronic lock 100 then sends a verification result of verifying the certificate chain back to the mobile device 200, 400.

If the authentication is passed, the mobile device 200, 400 will send a random challenge request to the electronic lock 100. The electronic lock 100 will calculate a random challenge and return the random challenge to the mobile device 200, 400. The mobile device 200, 400 relays the random challenge to the cloud account, e.g., via the platform cloud 1010 to the enterprise cloud 1020, which computes a digest (digest) of the hashed representation of the received challenge. Enterprise cloud 1020 will also calculate digital signatures using the digest of the platform cloud and a private key (e.g., key 940 described above). The cloud account returns the digital signature to the mobile device 200, 400, which in turn, the mobile device 200, 400 provides the digital signature to the electronic lock 100. The electronic lock 100 will similarly calculate a digest that represents a hash of the challenge sent to the mobile device 200, 400 and will verify the digital signature by using the calculated digest and the public key of the platform cloud (e.g., the public key of the public-key private key pair formed with the private key 940). The electronic lock 100 will send the result of the verification verifying the digital signature to the mobile device 200, 400. In this way, the mobile device may receive verification that the electronic lock has verified the cloud platform. At this stage, the cloud platform has been authenticated by the electronic lock 100.

Fig. 11 is a message flow diagram depicting a second portion 1100 of a secure communication procedure including mutual authentication, in accordance with an example embodiment. The second portion 1100 generally corresponds to authenticating the platform cloud of the electronic lock 100, thereby completing the mutual authentication process.

In the illustrated example, if the verification process is successful and the electronic lock has verified the cloud platform, the electronic lock 100 will send a device certificate (e.g., certificate 902) to the mobile device 200, 400. The mobile device in turn sends the locked device certificate to the platform cloud 1020, where the certificate chain of the device certificate is verified using the device certificate authority certificate (e.g., device certificate authority certificate 904) at the platform cloud 1020. The device's authentication result may then be returned to the mobile device.

If the device certificate is verified, the mobile device 200, 400 will next initiate a process of verifying the electronic lock to the cloud platform. In particular, the mobile device 200, 400 will send a request for a random challenge to a cloud account (e.g., to the enterprise cloud 1020 via the platform cloud 1010). The enterprise cloud 1020 will calculate and return the random challenge to the mobile device 200, 400 via the platform cloud 1010, and the mobile device 200, 400 will in turn provide the random challenge to the electronic lock 100. Electronic lock 100 hashes the calculated digest as a challenge and uses the calculated digest and the private key of the device (e.g., key 930 described above) to calculate another digital signature. The digital signature will be returned to the mobile device 200, 400, which in turn will be provided by the mobile device 200, 400 to the cloud account. Enterprise cloud 1020 will similarly compute a digest of the hash representing the challenge it provides to the mobile device. The enterprise cloud 1020 will verify the digital signature received from the electronic lock 100 using the corresponding digital signature represented by the digest and the public key of the electronic lock (e.g., the public key of the public-private key pair comprising private key 930). The enterprise cloud 1020 will return the verification results to the mobile device 200, 400 via the platform cloud 1010. Thus, the device certificate of the electronic lock 100 is also verified by the mobile device 200, 400. At this stage, mutual authentication between the electronic lock and the cloud account has been completed.

Fig. 12 is a message flow diagram depicting a third portion 1200 of a secure communication procedure including mutual authentication, according to an example embodiment. In this portion of the messaging sequence, mutual authentication has been completed and the electronic lock 100 and the mobile device 200, 400 may exchange encrypted objects for subsequent encrypted communications. In particular, in the illustrated example, the mobile device 200, 400 may send a message to the electronic lock 100 confirming that mutual authentication is complete. Because the cloud platform (including enterprise clouds 1020 and Ping Taiyun 1010) and electronic lock 100 are now authenticated to each other, and because the mobile application at mobile device 200, 400 is authenticated with respect to the cloud platform, a secure channel may be formed over the unsecure bluetooth connection between mobile device 200, 400 and electronic lock 100. In particular, in the example shown, the mobile device 200, 400 will generate a public-private key pair for key exchange. The mobile device 200, 400 sends the public key of the mobile device to the electronic lock 100. Meanwhile, the electronic lock 100 will generate a public-private key pair and send the public key of the electronic lock to the mobile device. The mobile device 200, 400 will use the private key of the mobile device and the public key of the electronic lock to calculate the shared secret. The electronic lock 100 will use the private key of the electronic lock and the public key of the mobile device to calculate the shared secret. An encrypted communication channel may be established between the mobile device and the electronic lock via bluetooth, for example, via a shared key generated using a shared secret.

Fig. 13 is a message flow diagram depicting an alternative third portion 1300 of a secure communication procedure including mutual authentication, according to an example embodiment. In this portion of the messaging sequence, mutual authentication has been completed and, as shown in fig. 12, the electronic lock 100 and the mobile device 200, 400 may exchange encrypted objects for subsequent encrypted communications.

Although the key exchange shown in fig. 12 relies on the exchange of public keys, in some cases it is preferable to avoid the communication of encryption keys or decryption keys used in the secure communication between the electronic lock 100 and the mobile device 200, 400 to improve protection against possible man-in-the-middle attacks between the electronic lock 100 and the mobile device 200, 400. Generally, and as discussed in more detail below, both the electronic lock 100 and the mobile application are authenticated to ensure that the encryption key is generated by the same trusted source as previously authenticated. In addition, the degree of randomness of the generated encryption key may be improved by using a key derivation function.

In particular, as seen in the third portion 1300 of the secure communication process, the mobile device 200, 400 may randomly generate a salt (salt) (designated as App salt in fig. 13, also referred to herein as "device salt") and a public-private key pair (App Pu, pk). The salt may be generated using a 256-bit random salt generated via a random number generator. In this case, the public-private key pair may be a key pair generated at an application using an Elliptic Curve (ECDH) public-private key generation process for key exchange with the electronic lock 100. The salt and application public key may be sent from the mobile device 200, 400 to the platform cloud 1010. The platform cloud 1010 will calculate a platform digest by hashing the salt and application public key, and will then use the calculated platform digest and the private key of the platform cloud 1010 to generate a platform signature. In this example, the private key of the platform cloud 1010 may be a private key of a platform certificate, such as private keys 940a-n described above in connection with FIG. 9. In an example embodiment, a SHA2 hashing algorithm may be used; however, in alternative embodiments, other types of hashing algorithms may be used.

The platform cloud 1010 then sends the platform signature back to the mobile device 200, 400. The mobile device 200, 400 will sign the salt and application public key using the platform signature and then send it to the electronic lock 100.

At the electronic lock 100, the platform public key is used to verify a platform signature received from the platform cloud 1010 via the mobile device 200, 400. In this case, the platform public key may be a platform certificate key, such as may be included in the public cloud certificate authority certificate 916 described above in connection with fig. 9. If the platform signature is successfully verified, the electronic lock 100 will generate a lock salt (similar to the device or application salt described above) and a lock public-private key pair. As described above, the lock public-private key pair may be a key pair generated at the electronic lock using an Elliptic Curve (ECDH) public-private key generation process for key exchange with the mobile device 200, 400. The electronic lock 100 will generate a lock digest by hashing the lock salt and the lock public key, and will then generate a lock signature from the lock digest and a lock private key from the lock certificate, such as private keys 930a-n of fig. 9.

The electronic lock 100 sends the signed lock salt and the lock public key of the ECDH key pair of the lock to the mobile device 200, 400, which in turn passes the lock signature to the platform cloud 1010. The platform cloud 1010 will verify the lock signature using the received lock public key and return the verification result to the mobile device 200, 400.

At this stage, both the mobile device 200, 400 and the electronic lock 100 have been authenticated with respect to each other and with respect to the platform cloud 1010, because the electronic lock 100 has authenticated that the applied ECDH key is from the same device as previously authenticated, and the platform cloud has authenticated that the key of the electronic lock 100 is from the same electronic lock as previously authenticated (in fig. 10-12). Thus, each of the mobile device 200, 400 and the electronic lock 100 may generate encryption and decryption keys for secure channel communications therebetween, provided that authentication has successfully occurred.

In particular, in the example shown, the mobile device 200, 400 and the electronic lock 100 will each use ECDH keys generated at the application and the lock to generate a shared secret. In particular, the mobile device 200, 400 will generate a shared secret using the application private key and the lock public key, while the electronic lock 100 will generate a shared secret using the lock private key and the application public key. At the mobile device 200, 400, the encryption key may be generated using the application salt, the shared secret generated at the mobile device 200, 400, and the lock identifier (lock ID). The mobile device 200, 400 will also use the lock salt, the shared secret and the lock ID to generate a decryption key.

At the electronic lock 100, an encryption key is generated from the shared secret, the lock ID, and the lock salt. In addition, a decryption key is generated from the application salt, the shared secret, and the lock ID. Note that the encryption key generated at the electronic lock 100 is equivalent to the decryption key generated at the mobile device 200, 400, and the decryption key generated at the electronic lock 100 is equivalent to the encryption key generated at the mobile device 200, 400.

In an example embodiment, the computation of the encryption and decryption keys at the mobile applications 200, 400 and the electronic lock 100 may be performed using a key derivation function, such as an HMAC Key Derivation Function (HKDF), to generate AES256 encryption and decryption keys. Alternative key derivation functions may also be used.

Upon completion of the generation of the encryption key and the decryption key at the mobile device 200, 400 and the electronic lock 100, encrypted communications may be established between these devices. Thereafter, a secure channel is established between devices that are not dependent on local bluetooth key management at the mobile device 200, 400. Instead, depending on the particular mobile device used, the mobile device 200, 400 may store encryption and decryption keys associated with an identifier of the electronic lock (or electronic lock-mobile device pair), for example using an iOS keychain in iOS or in Android keystore systems. Similarly, the electronic lock 100 will use a secure element in the BLE control unit to store encryption and decryption keys that are associated with identifiers provided by the mobile application for matching during a subsequent BLE communication session. That is, the encryption and decryption keys generated by the process depicted in fig. 13 may be maintained at the mobile devices 200, 400 and electronic lock 100 for subsequent communications between these particular devices. The encryption key and decryption key may be maintained in those devices until the lock is deactivated, factory settings are restored, or until access to the lock is revoked, for example, by a administrative user.

Referring to fig. 14, another communication sequence 1400 is shown that illustrates subsequent communications between the mobile device 200, 400 and the electronic lock 100. In this case, the mobile device 200, 400 will identify the particular key pair for communicating with the particular electronic lock 100 via the secure channel. The mobile device 200, 400 will send a message to the electronic lock 100 that includes an identifier, such as the identifier described above, that remains associated with the generated key pair at both the mobile device 200, 400 and the electronic lock 100. The electronic lock 100 may then retrieve the appropriate key pair based on the identifier and may establish encrypted communications between the devices. Thus, a secure channel may be established between the mobile device 200, 400 and the electronic lock 100 without the need to regenerate the encryption key and the decryption key at the respective devices.

Referring generally to the above process, it should be noted that certain aspects may be performed in a different order. For example, in some implementations, the electronic lock may be authenticated to the cloud account prior to authentication of the cloud account to the electronic lock, and vice versa (e.g., exchanging portions of the processes shown in fig. 10-11, respectively). Additionally, referring generally to fig. 13, it is noted that in different embodiments, certain steps within the third portion 1300 may be performed in a different order. For example, in some cases, the electronic lock 100 may generate a lock salt and public/private key, a lock digest, and a lock signature for verification at the platform cloud 1010 before the mobile device 200, 400 generates an application salt, an application public/private key, and the platform cloud 1010 generates a platform digest and signature for verification at the electronic lock 100. That is, the order in which the signatures are verified between the platform cloud 1010 and the electronic lock 100 is a matter of design choice.

Further, the above-described methods and process flows of fig. 10-14 are shown as occurring without the need for a corresponding binding process between an electronic lock and a mobile device (e.g., mobile device 200, 400). While such a binding process may be used at the initial connection in fig. 10 and removed when secure communication occurs in fig. 14, such a configuration is optional and completely precluded in at least some cases, for example, where the mobile device is configured for sequential pairing and configuration of an electronic lock.

In addition, while the above-described mutual authentication procedure is described as being performed by a plurality of mobile devices including the administrator mobile device 200 and the guest mobile device 400, it should be appreciated that other configurations may be used. For example, after the administrator mobile device 200 has performed a mutual authentication process and has exchanged a public key with the electronic lock 100, in alternative embodiments, the administrator mobile device 200 may synchronize the lock public key and optional shared key to the cloud for sharing with other devices; in this way, the guest mobile devices will be able to be authenticated by the cloud and will receive the shared key, allowing those guest mobile devices to communicate with the electronic lock without having to perform the mutual authentication process described above. Because the keys are stored in secure locations within the application storage device and within the electronic lock, the compromise of such keys is minimized.

Furthermore, where the key of each electronic lock is unique, in an exemplary embodiment, a re-authentication process may be required each time the electronic lock is powered on to cycle. For example, upon power-on cycling of the electronic lock, a new mutual authentication procedure may be required during the next communication sequence with a trusted mobile device (e.g., administrator mobile device 200 or guest mobile device 400) and a new set of encryption keys (and new shared keys) are generated and optionally propagated to other authorized mobile devices.

For example, embodiments of the present invention have been described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the invention. The functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

The descriptions and illustrations of one or more embodiments provided herein are not intended to limit or restrict the scope of the claimed invention in any way. The embodiments, examples, and details provided in this application are believed to be sufficient to convey ownership and enable others to make and use the best mode of the claimed invention. The claimed invention should not be construed as limited to any of the embodiments, examples, or details provided in this application. Whether shown and described in combination or separately, the various features (both structures and methods) are intended to be selectively included or omitted to produce embodiments having particular feature sets. Having provided the description and illustration of the present application, one skilled in the art may contemplate variations, modifications, and alternative embodiments that fall within the spirit of the broader aspects of the general inventive concepts embodied in the present application, without departing from the broader scope of the claimed invention.

Claims

1. A method of establishing secure communications with a mobile device at an electronic lock, the method comprising:

establishing a communication connection with a mobile device via a short range wireless communication protocol;

performing at least a portion of a mutual authentication procedure in which the electronic lock is authenticated to the mobile device and the mobile device is authenticated to the electronic lock;

performing a key generation process with the mobile device to generate an encryption key and a decryption key at the electronic lock; and

an encrypted communication with the mobile device is performed using the generated encryption key and the decryption key, the encrypted communication occurring via an unbound connection using the short-range wireless communication protocol.

2. The method of claim 1, wherein the encrypted communication with the mobile device comprises: the method includes receiving a communication from the mobile device encrypted with a mobile device encryption key, and decrypting the communication from the mobile device using the decryption key, the decryption key corresponding to the mobile device encryption key.

3. The method of claim 1, wherein the encryption key is equivalent to a decryption key of the mobile device.

4. The method of claim 1, wherein performing the mutual authentication procedure comprises:

a mobile device authentication phase comprising:

receiving a certificate from the mobile device;

validating the certificate at the mobile device relative to a public version of the certificate;

sending a random challenge to the mobile device;

receiving a digital signature from the mobile device, the digital signature generated by a certificate holder and based at least in part on the random challenge;

verifying the digital signature based on the random challenge and a public key of the certificate holder; and

transmitting a result of verifying the digital signature to the mobile device; and

an electronic lock authentication phase comprising:

sending a lock certificate to the mobile device; and

a lock digital signature is sent to the mobile device, the lock digital signature generated based on a second random challenge.

5. The method of claim 4, wherein the lock digital signature is generated at the electronic lock and the second random challenge is received from the mobile device.

6. The method of claim 4, wherein performing the key generation process comprises: a lock public key-private key pair is generated at the electronic lock.

7. The method according to claim 1,

wherein establishing the communication connection with the mobile device comprises performing a binding procedure to form a binding communication connection with the mobile device, the binding procedure comprising exchanging a binding key pair with the mobile device via the short range wireless communication protocol;

the method further comprises the steps of: after performing at least a portion of the mutual authentication procedure, tearing down the bonded communication connection with the mobile device; and

wherein the electronic lock does not store a long-term key that is used as part of the binding process for encrypted communications via the unbound connection.

8. The method of claim 1, further comprising:

receiving an indication from the mobile device that a user account has been deactivated; and

discarding the encryption key and the decryption key at the electronic lock in response to the indication.

9. An electronic lock, comprising:

a programmable circuit;

a short-range wireless communication interface communicatively coupled to the programmable circuit;

a memory storing instructions that, when executed, cause the programmable circuitry to:

establishing a communication connection with a mobile device via the short-range wireless communication interface through a short-range wireless communication protocol;

an encrypted communication with the mobile device is performed using the encryption key and the decryption key, the encrypted communication occurring via the short range wireless communication interface using the short range wireless communication protocol via an unbound connection.

10. The electronic lock of claim 9, wherein the encrypted communication includes one or more commands to actuate a motor to move a latch of the electronic lock between an extended position and a retracted position.

11. The electronic lock of claim 9, wherein the short-range wireless communication protocol comprises bluetooth.

12. The electronic lock of claim 9, wherein the mutual authentication procedure comprises a mobile device authentication phase and an electronic lock authentication phase;

the mobile device authentication phase includes the electronic lock configured to:

receiving a certificate from the mobile device;

Verifying the certificate at the mobile device relative to a public version of the certificate;

sending a random challenge to the mobile device;

the electronic lock authentication phase includes the electronic lock configured to:

sending a lock certificate to the mobile device; and

13. The electronic lock of claim 12, wherein the lock certificate is signed by a certificate authority associated with a manufacturer of the electronic lock.

14. The electronic lock of claim 12, wherein the certificate authority shares a public enterprise root certificate with a certificate received from the mobile device.

15. The electronic lock of claim 12, wherein the encryption key comprises a shared key generated from a device key and a lock key.

16. The electronic lock of claim 9, further comprising storing the encryption key and the decryption key in a memory of the electronic lock independent of the short-range wireless communication interface.

17. A method of establishing secure communications between a mobile device and an electronic lock, the method comprising:

establishing a communication connection between the electronic lock and the mobile device via a short range wireless communication protocol;

performing a mutual authentication procedure in which the electronic lock is authenticated to the mobile device and the mobile device is authenticated to the electronic lock;

performing a key generation process, the key generation process comprising:

generating a lock salt, a lock public key and a lock private key at the electronic lock, wherein the lock public key and the lock private key form a lock public key-private key pair;

generating, at the mobile device, a device salt, a device public key, and a device private key, the device public key and the device private key forming a device public key-private key pair;

generating a platform signature at a platform cloud, the platform signature being a platform digest signed by a platform private key, the platform digest formed by the device salt and a device public key;

generating a lock signature at the electronic lock, wherein the lock signature is a lock digest signed by a lock private key, and the lock digest is formed by the lock salt and a lock public key;

Verifying the platform signature at the electronic lock using a platform public key;

verifying the lock signature at the platform cloud using the lock public key;

generating a lock encryption key and a lock decryption key at the electronic lock based on verifying the platform signature at the electronic lock;

generating, at the mobile device, a mobile device encryption key and a mobile device decryption key based on verifying the lock signature at the platform cloud; and

using the short range wireless communication protocol, encrypted communication is performed between the mobile device and the electronic lock using the mobile device encryption key, the mobile device decryption key, the lock encryption key, and the lock decryption key.

18. The method of claim 17, wherein the mutual authentication procedure comprises: a certificate of the mobile device is verified at the electronic lock based on a digest calculated from a challenge received from the mobile device and a public key received from the mobile device.

19. The method of claim 17, further comprising:

disabling an account of a user associated with the mobile device;

during encrypted communication between the mobile device and the electronic lock, the encryption key and the decryption key are deleted from a memory of the electronic lock.

20. The method of claim 17, wherein the mobile device has an application installed thereon that manages communications with the electronic lock and a cloud account associated with the application to perform at least a portion of the mutual authentication procedure.

21. The method of claim 17, wherein generating the encryption key and the decryption key at the mobile device comprises:

generating the mobile device encryption key by providing the device encryption salt, lock identifier, and shared secret to a key derivation function;

generating the mobile device decryption key by providing the lock salt, the lock identifier, and a shared secret to the key derivation function;

generating the lock encryption key by providing the lock salt, the lock identifier, and the shared secret to a key derivation function; and

the lock decryption key is generated by providing the device salt, the lock identifier, and the shared secret to the key derivation function.

22. The method of claim 21, wherein the mobile device encryption key corresponds to the lock decryption key and the mobile device decryption key corresponds to the lock encryption key.

23. The method according to claim 17,

wherein establishing the communication connection includes performing a binding process to form a binding communication connection between the electronic lock and the mobile device, the binding process including exchanging a binding key pair between the electronic lock and the mobile device via the short range wireless communication protocol;

the method further comprises the steps of: removing the binding communication connection with the mobile device after performing at least a portion of the mutual authentication procedure;

wherein the encrypted communication is performed using an unbound connection between the electronic lock and the mobile device, and wherein the electronic lock does not store a long-term key that is used as part of the binding process for encrypted communication via the unbound connection.