Button protocol

Abstract

Accordingly, a method and a device for performing a button protocol between a first device and a second device are provided. The method comprises: sending, by a first device, a first message after receiving a first button press; listening for the second message until the end of the waiting time or until a third button press is received (what is earlier); entering a security phase of the button protocol if one or more second messages have been received from only one device; and aborting the button protocol if the second message has not been received or if the second message has been received from more than one device. In another case, the method includes monitoring a first message after receiving a first button press; if the first message has been received, transmitting, by the first device, a second message until the end of the waiting time or until the third button is pressed (what is earlier); entering a security phase if one or more first messages have been received from only one device; and aborting the button protocol if the second message has not been received or if the second message has been received from more than one device.

Description

Technical Field

[0001] The present invention relates to devices and methods for wireless networks, particularly those compliant with the IEEE 802.11 family of standards. Background Art

[0002] Figure 1 A wireless network 1 is represented, which includes a first device 2 and another device 3. The first device 2 may have a central function, similar to an access point (AP), a hub or a gateway device. For simplicity, the first device 2 will be referred to as an AP hereinafter, but other types of devices are certainly possible. A user (not shown) wishes to add two further devices to the network 1, namely a complex device 4 (here represented as a computer) and a simple device 5 (here represented as a toothbrush). Devices like the simple device 5 typically do not have any real user interface (UI) except possibly a light, and are therefore often referred to as "headless" devices. The AP 2 has a processor 6, and the simple device 5 has a microcontroller, a small non-volatile memory 7 and a button 8, which can be used to reset the simple device 5. There is also a third device 9.

[0003] Some wireless network standards allow one device to configure another device in order to establish a connection and communication. This makes the task of adding or registering a new device in the network less cumbersome because the user no longer has to perform manual input.

[0004] See reference [DH], Diffie-Hellman is a well-known technique for establishing a secret key between two parties, where the communication between the parties used to establish the secret key does not reveal any information about the established secret key to third parties. The two parties each use their own public / private key pair and exchange public keys with each other. Each party is able to calculate the secret key using its own private key and the other party's public key and possibly some other information (e.g., a nonce (random number) from each party). Each party can regenerate a key pair each time it performs Diffie-Hellman or reuse an older key pair.

[0005] Commissioning protocols such as the Wi-Fi Alliance's Device Provisioning Protocol (DPP) (see reference document [DPP]) use Diffie-Hellman to establish secret keys between two devices (a DPP participant that wants to be configured and a DPP Configurator that is capable of configuring the DPP participant) so that they can access a DPP-enabled network or can set up a DPP-enabled network as an access point (AP) (see reference document [802.11]).

[0006] When Diffie-Hellman is performed over a network, the device that receives the public key used to perform Diffie-Hellman does not know which device that public key came from. This can be exploited by an attacker in a so-called man-in-the-middle attack. An attacker E might pretend to be the real device B that device A wants to connect to. Attacker E performs Diffie-Hellman with device A and establishes a key Kae with device A. Similarly, the attacker pretends to be device A against device B and establishes a key Kbe with device B. When a message comes in from one of devices A or B, the attacker decrypts the message with one secret key, encrypts it with another secret key and forwards it to the other device. This way, devices A and B don't notice anything strange in their communication, except for some extra delays. When they check their communication by sending the same information using another means of communication and comparing the results, they don't notice any tampering with their communication. But the attacker has full knowledge of what they are communicating. Summary of the invention

[0007] Therefore, it is desirable to provide a push button protocol to address these issues.

[0008] Therefore, a method for performing a button protocol between a first device and a second device is provided, comprising: sending a first message by the first device after receiving a first button press, listening for a second message until a waiting time expires, wherein the waiting time is shortened by detecting subsequent button presses on the first device, entering a safe phase of the button protocol if one or more second messages are received from only one device, and aborting the button protocol if no second message is received or if second messages are received from more than one device.

[0009] A method for performing a button protocol between a first device and a second device is also provided. The method includes: listening by the first device until a waiting time expires, wherein the waiting time is shortened by detecting subsequent button presses on the first device to obtain a first message after receiving the first button press; sending a second message by the first device if the first message has been received; entering a security phase if one or more first messages have been received from only one device; and aborting the button protocol if the first message has not been received or if the first message has been received from more than one device.

[0010] The additional button presses allow for improvements in both the security and reliability of the protocol. This is because the waiting time (i.e., walk time) may be shortened, thereby limiting the window in which an illegitimate device has to attempt to connect by sending messages to or listening for messages from one or both of the two devices that the user is actually trying to configure and connect. However, the walk time is shortened only if the user can confirm that this is appropriate, thereby maintaining a good chance of the protocol completing successfully.

[0011] In an aspect, the first device may send the first message on more than one channel.

[0012] In an aspect, the first device may listen for the first message on more than one channel.

[0013] By using multiple channels, the robustness of the protocol is improved.

[0014] In one aspect, the first message may be a button presence notification, the second message may be a button presence notification response, and the security phase of the protocol begins with the PKEX protocol from the Device Provisioning Protocol (DPP).

[0015] A device arranged for participating in a button protocol is provided. The device comprises a button and a processor, the processor being arranged to start a wait time timer after detecting a first button press on the button, send a first message by a first device after detecting the first button press, listen for a second message until the wait time expires, wherein the wait time is shortened by detecting subsequent button presses on the first device, enter a safety phase of the button protocol if one or more second messages are received from only one device, and abort the button protocol if no second message is received or if a second message is received from more than one device.

[0016] A device arranged to participate in a push button protocol is also provided. The device comprises a push button and a processor, the processor being arranged to start a wait time timer after detecting a first button press on the button, listening until the wait time expires, wherein the wait time is shortened by detecting subsequent button presses on a first device to obtain a first message after receiving the first button press, if the first message has been received, sending a second message, if one or more second messages have been received from only one device, entering a secure phase; and aborting the push button protocol if the first message has not been received or if the first message has been received from more than one device.

[0017] A computer program product is also provided which, when executed on a processor of a device as described herein, causes the processor to perform the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and additional objects, features and advantages of the disclosed apparatus, system and method will be better understood through the following illustrative and non-limiting detailed description of embodiments of the apparatus and method with reference to the accompanying drawings, in which:

[0019] Figure 1 Indicates the wireless network for which you need to configure the device to add it.

[0020] Figure 2 Represents the flow of a known configuration process.

[0021] Figure 3 Flow diagram showing a known configuration process according to an embodiment.

[0022] Figure 4 represents a device according to an embodiment.

[0023] Figure 5 It indicates a storage medium for holding a computer program for executing the process according to the embodiment. DETAILED DESCRIPTION

[0024] In the following description, the same reference numerals denote the same elements.

[0025] Figure 2 The flow chart of the configuration method of device control according to the embodiment is shown, in which a device (such as Figure 1 A third device 9 or AP2) may be configured and connected to another device (such as Figure 1 Complex device 4 or simple device 5). Figure 1 The third device 9 may configure another device such as Figure 1 A complex device 4 or a simple device 5 is provided to enable another device to connect to AP2. A third device 9 and devices 4 and 5 are according to an embodiment. As an example, the case of a simple device 5 will be discussed. It should be understood that although most of this specification provides examples involving a network with devices like AP2, the process can work in a peer-to-peer situation.

[0026] One way for a user to ensure that the configurator and participants performing Diffie-Hellman (e.g., at the beginning of the configuration protocol specified in [DPP] or [WPS]) are indeed the devices that the user wants is the push-button method, such as described in [DPP] Section 5.8, "PKEX-based Push Button" or in [WPS] 11, "Push-button Configuration".

[0027] The push button protocol is also used in many other networks, such as networks for device pairing. The push button protocol can be summarized as follows. A user wants two wireless devices to securely participate in a protocol, such as a protocol in which one of the devices (the configurator) configures the other device (the participant), for example, to be able to access a certain network. In the case of object pairing, the process is similar in important respects.

[0028] At S1, the user presses a button, a first button, on one of the devices. At this point, it does not matter whether the first device is a configurator or a participant. Depending on the details of the particular button protocol, the first device begins listening for a first button message that the other device wants to participate in executing the button protocol, or the other device begins sending a first button message that it wants to participate in executing the button protocol. Figure 2 In the example above, for simplicity, the case where the first device sends a message is shown. The first device only does this for a specific amount of time (the walking time). S2, the user presses a button on the second device - the second button press. The two devices may be located relatively far apart in the house, such as a device, a Wi-Fi access point (AP) with configurator functionality in the basement and a smart water heater in the attic that uses Wi-Fi to connect to the power company, hence the term "walking time". Due to this distance, the walking time in WPS is set to 120 seconds and in DPP, which is referred to as the first listening period, is set to 100 seconds.

[0029] After the second button press and depending on the details of the particular button protocol, the second device begins sending first button messages that it wants to participate in executing the button protocol, or the second device begins listening for first button messages from another device that wants to participate in executing the button protocol. The second device will also only do this for a specific amount of time, which can be the same as the walk time of the first device or a different walk time.

[0030] The device that starts sending the first button message is referred to herein as an initiator, and the device that starts listening for the first button message is referred to as a responder. The initiator may be the first device or the second device, and the responder may be the second device or the first device.

[0031] In [DPP], the first message is a button presence notification, the second message is a button presence notification response, the device referred to herein as the initiator is referred to in [DPP] as a participant, and the responder is referred to in [DPP] as a configurator.

[0032] In [WPS], the first message is a probe request with a device password ID and a WSC IE (Wi-Fi Simple Configuration Information Element), see, for example, [WPS] section 11.3, the second message is a probe response indicating a selected Registrar (WPS name for Configurator) with a PBC (Push Button Configuration) device password ID and a WSCIE, see [WPS] section 11.3, what we call an initiator in this application is called a participant in [WPS], and what we call a responder in this application is called a Registrar in [DPP]. The Registrar can be considered a Configurator and is typically located in a Wi-Fi AP.

[0033] Depending on the details of the particular button protocol, the initiator cycles through all channels it supports for sending the first message while the responder listens on one channel, or the responder cycles through all channels it supports for listening for the first message while the initiator sends the first message on one channel.

[0034] In [DPP] and [WPS], the initiator cycles through all channels, while the responder listens on one channel.

[0035] As in the case of [DPP], if the responder device is unknown, the first message may be sent to a broadcast address. In [WPS], a participant (i.e., the initiator) may find out which Registrars are active by checking whether the beacon signal of an AP that supports the Registrar incorporates a Selected Registrar flag set to TRUE.

[0036] When the responder does not receive any first message during the walk time, the responder aborts the push button protocol and the protocol fails. When the responder has received the first message from more than one device during the walk time, the responder aborts the push button protocol and the protocol fails. This is because in the latter case, there are two or more potential candidates to further participate in the protocol, but the responder does not know which of these candidates is the expected candidate. We call the expected initiator the expected initiator, and the other initiators are called illegal initiators. The protocol continues only when the responder receives the first message from one initiator.

[0037] The responder will respond with the second message upon receiving the first message. Exactly when this happens depends on the specific button protocol. It may happen, for example, immediately after reception or after having cycled through all channels and no illegal initiators have been detected.

[0038] Similar to the responder case described above, when the initiator does not receive any second message during the walk time, the initiator aborts the push button protocol and the protocol fails. When the initiator receives a second message from more than one device during the walk time, the initiator aborts the push button protocol and the protocol fails. This is because in the latter case, there are two or more potential candidates to further participate in the protocol, but the initiator does not know which of these candidates is the expected candidate. We refer to the expected responder as the expected responder and the other responders as illegal responders. The protocol continues only when the initiator receives a second message from one responder.

[0039] The above-mentioned push button protocol or just the protocol for short consists of two phases. The phase of exchanging the first message and the second message can be called the discovery phase of the protocol. This is completed at step S3. After the discovery phase is successful, the security phase of the protocol begins, in which the two devices can securely participate in another protocol, such as a bootstrap protocol like the PKEX protocol in [DPP], or a configuration protocol, as shown in Figure 18 starting from "Authentication Request" up to and including all messages of "EAP Response (Complete)" - the PBC message exchange of [WSC]. This part ends at S4 (End). The process is completed in Figure 2 Indicated by "Secure Exchange".

[0040] The problem with the button protocols described above is that they take at least a walking time, which takes about two minutes to complete. This is a very long waiting time for the user, especially if both devices are within the user's reach and their buttons can be pressed within a few seconds. On the other hand, the walking time must be long enough to allow the user to pass between the devices in most cases. During this time, the devices are open to attack. Therefore, this process has disadvantages.

[0041] The discovery phase of the protocol can be shortened by having the responder reply immediately to the first received first message, or at the latest after going through all the channels it supports once again, and then entering the security phase of the protocol, taking into account its walk time, if it has not received the first message from more than one device. This can be enhanced by requiring the initiator and / or responder to listen to the second message and the first message, respectively, before pressing the button, and retaining a list of these messages returned, for example, at least during the walk time. However, the inventors have realized that the disadvantage of this solution is that, in the case where the responder receives the first message, the responder does not know whether the first message is from the expected device or from an illegal device. In addition, there may be the following situation: if the responder enters and completes the security phase of the protocol before the walk time is really over, the user may have performed the first button press on the responder and still "walk" to the initiator, i.e. the expected initiator, to perform the second button press. In addition, the discovery phase may be terminated abruptly due to the receipt of a message from another (possibly illegal) device without the responder starting the security phase. In either case, any message from the expected initiator will arrive at the responder too late, with the result that the protocol is unnecessarily aborted.

[0042] Figure 3 The process according to the embodiment is shown in FIG. Figure 2The same elements are not repeated in detail in the process. After the second button press, i.e. after the user has pressed the button on the second device, at S3a, the user returns to the first device and presses its button for the second time. This button press is referred to as the third button press. Compared to that specified in [WSC], this third button press indicates that the walk time for the first device has ended, and the first device can continue with the safe phase of the protocol, i.e. continue to S4. Optionally, the user presses the button on the second device for the second time, which we call the fourth button press, which signals the second device that its walk time has ended.

[0043] Note that in [WPS], a third or fourth button press on a device instructs the device to restart the push button protocol, which is a very different action from that described herein.

[0044] Similarly, if the user has performed a button press on the initiator, and the initiator is allowed to continue with the secure phase of the protocol when a second message is received before its walk time has expired, it does not know whether the received second message is from the intended device or an illegitimate device, relying solely on not receiving any second message from another device in the period before its button was pressed. It is possible that if the initiator enters and completes the secure phase of the protocol before the walk time has actually expired, the user has performed a first button press on the initiator, and still "walks" to the responder (the intended responder) to perform a second button press. Any message from the intended initiator will arrive at the responder too late.

[0045] If the first device (responder or initiator) receives a third button press from the user, the first device knows that the second device has time to send the first message (if the second device is the initiator) or the second message (if the third device is the responder). Optionally, to increase the certainty of this determination, after the third button press, if the first message or the second message has not been received from more than one device at the latest at the time of the first button press, the first device cycles through all channels it supports before entering the security phase of the protocol. If the walking time ends, the first device can still continue with the security phase of the protocol even if it did not receive the third button press.

[0046] The advantage is that having received the third button press, the first device can enter the secure phase of the protocol faster than the walk time, while being certain that it is engaging with the intended second device and not some other (potentially malicious) illegitimate device. Another advantage is that shortening the walk time by active action by the user, rather than allowing the device to decide this, can give the user time to actually press the button on the respective device.

[0047] However, after receiving the first message (when the second device is the responder) or the second message (when the second device is the initiator) with the second button press, the second device cannot enter the secure phase of the protocol on the basis that it knows with certainty that the message is from the expected first device. It can be considered that it is not important that the first device is ready to start the second phase of the protocol while the second device is not yet sure. However, it may be advantageous to optionally add another button press. If the user presses the button a second time on the second device after the third button press on the first device, i.e., the fourth button press, the second device also knows that the first device has time to send its first message or second message. Figure 3 The fourth button press is not shown in FIG. In the case where the fourth button press is used, the fourth button press will trigger the start of the second stage, rather than triggering the third button press as in S3a.

[0048] Optionally, to increase the certainty of this determination, after the fourth button press, the second device cycles through all channels it supports before continuing to the secure phase of the protocol if it has not received a first message (if it is a responder) or a second message (if it is an initiator) from more than one device since the most recent second button press. In any case, if the walk time ends and it has not received a fourth button press, the second device may continue to the secure phase of the protocol.

[0049] At first glance, this may seem counterintuitive because if the user has to go to the second device to perform the second button press, return to the first device to perform the third button press and go to the second device again to perform the fourth button press, this may be seen as a burden on the user. However, if the distance between the two devices is such that moving back and forth between them exceeds the walking time of the protocol, the user does not have to perform the fourth button press or the third and fourth button presses because the protocol is completed before the user can perform the third or fourth button press. However, if the devices are close together, the third and fourth button presses will not be a burden on the user, and in this case, the time to perform the protocol will be much shorter than the walking time, which is an advantage for the user. In addition, even if the user has to change position to perform the third and possible fourth button presses, the additional safety and reliability of the protocol may justify this additional burden.

[0050] It should be understood that although the example used in the description of the button protocol is using Wi-Fi, the button protocol and the improvements proposed in this application can use any wireless technology, such as Bluetooth [BT], ZigBee, etc.

[0051] Figure 440 represents a device according to an embodiment. The device 40 has a processor 41, an optional transceiver 42 and a button 43 and an optional input / output port 44. The device 40 may also have a storage unit (not shown) for storing computer program code. The input / output port 44 may be used to connect the device to an external transceiver, wherein the transceiver 42 is not physically present in the device 40. The transceiver is arranged to send and receive messages according to the wireless technology involved.

[0052] Figure 5 A storage medium 50 is represented for storing a computer code which, when installed on a device 40, enables the device 40 to perform a method according to an embodiment. The storage medium 50 may be a part of the device 40 or a separate storage unit, such as a data carrier or even a remote server.

[0053] In summary, a method for executing a button protocol between a first device and a second device includes: sending a first message by the first device after receiving a first button press; listening for a second message until a waiting time expires or the earlier of subsequent button presses on the first device is detected; entering a safe phase of the button protocol if one or more second messages are received from only one device; and aborting the button protocol if no second message is received or if a second message is received from more than one device.

[0054] There is also a method of performing a button protocol between a first device and a second device. The method includes: after receiving a first button press, listening for a first message until the earlier of a wait time expires or a subsequent button press on the first device is detected; if the first message has been received, sending a second message by the first device; if one or more first messages have been received from only one device, entering a security phase; and if the first message has not been received or if the first message has been received from more than one device, aborting the button protocol.

[0055] The additional button presses allow for improvements in both the security and reliability of the protocol. This is because the waiting time (i.e., walk time) may be shortened, thereby limiting the window in which an illegitimate device has to attempt to connect by sending messages to or listening for messages from one or both of the two devices that the user is actually trying to configure and connect. However, the walk time is shortened only if the user can confirm that this is appropriate, thereby maintaining a good chance of the protocol completing successfully.

[0056] The first device may send the first message on more than one channel.

[0057] The first device may listen for the first message on more than one channel.

[0058] By using multiple channels, the robustness of the protocol is improved.

[0059] The first message may be a button presence notification, the second message may be a button presence notification response, and the security phase of the protocol begins with the PKEX protocol from the Device Provisioning Protocol (DPP).

[0060] There is a device arranged to participate in a button protocol. The device comprises a button and a processor arranged to: start a wait time timer after detecting a first button press on the button; send a first message by a first device after detecting the first button press; listen for a second message until the earlier of the wait time expires or a subsequent button press on the first device is detected; enter a safety phase of the button protocol if one or more second messages are received from only one device; and abort the button protocol if no second message is received or if the second message is received from more than one device.

[0061] There is also a device arranged to participate in a button protocol. The device includes a button and a processor, the processor being arranged to: start a wait time timer after detecting a first button press on the button; after detecting the first button press, listen for a first message until the wait time expires or a subsequent button press on the first device is detected, whichever is earlier; if the first message has been received, send a second message; if one or more second messages have been received from only one device, enter a safety phase of the button protocol; and if the first message has not been received or if the first message has been received from more than one device, abort the button protocol.

[0062] A computer program product is also provided which, when executed on a processor of a device as described herein, causes the processor to perform the method described herein.

[0063] Aspects of the embodiments may be implemented in a computer program product, which may be a collection of computer program instructions stored on a computer-readable storage device that may be executed by a computer. Instructions may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs) or Java classes. Instructions may be provided as complete executable programs, partial executable programs, modifications (e.g., updates) to existing programs, or extensions (e.g., plug-ins) to existing programs. In addition, partial processing of the present invention may be distributed on multiple computers or processors.

[0064] Storage media suitable for storing computer program instructions include all forms of non-volatile memory, including but not limited to EPROM, EEPROM and flash memory devices, magnetic disks such as internal and external hard drives, removable disks and CD-ROM disks. The computer program product may be distributed on such storage media or may be provided for download via HTTP, FTP, email or through a server connected to a network such as the Internet.

[0065] The following documents can be used as reference:

[0066] [802.11] IEEE Computer Society, "IEEE Standard for Information Technology–Telecommunications and Information Exchange Between Systems–Localand Metropolitan Area Networks–Specific requirements Part 11: Wireless LANMedium Access Control (MAC) and Physical Layer (PHY) Specifications," (IEEEStd.802.11-2016), December 2016.

[0067] [BT]Bluetooth Core Specification,v5.0,https: / / www.bluetooth.com / specifications / bluetooth-core-specification / bluetooth5,December 2016.

[0068] [DH]Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEETransactions on Information Theory, 22(6):644–654.

[0069] [DPP]Proposal to add Push Button bootstrapping to Device ProvisioningProtocol–Technical Specification-Version 2.0.0.6,Wi-Fi Alliance,2022,https: / / groups.wi-fi.org / apps / org / workgroup / wfa-wifieasyconnect-tg / download.php / 119571 / Wi-Fi_Easy_Connect_Specification_v2.0%200.6_PB4.docx.

Claims

1. A method for executing a button protocol between a first device and a second device, the method comprising: - after receiving the first button press, sending, by the first device, a first message; - listening for a second message until a waiting time expires, wherein the waiting time is shortened by detecting a subsequent button press on the first device; - if one or more second messages have been received from only one device, entering the secure phase of the push button protocol, and - If the second message has not been received or if the second message has been received from more than one device, aborting the button protocol.

2. A method for executing a button protocol between a first device and a second device, the method comprising: - listening, by the first device, for a first message after receiving a first button press until a waiting time expires, wherein the waiting time is shortened by detecting subsequent button presses on the first device; - if the first message has been received, sending a second message by the first device; - if one or more first messages have been received from only one device, then entering the security phase, and - If the first message has not been received or if the first message has been received from more than one device, aborting the button protocol.

3. The method according to claim 1, wherein: The first device sends a first message through more than one channel.

4. The method according to claim 2, wherein: The first device listens on more than one channel for a first message.

5. The method according to claims 1 to 4, wherein: The first message is a button presence notification, the second message is a button presence notification response, and the security phase of the protocol starts with the PKEX protocol from the Device Provisioning Protocol (DPP).

6. A device arranged to participate in a push button protocol, the device comprising a push button and a processor, the processor being arranged to: - starting a waiting time timer after detecting a first button press on said button; - after detecting the first button press, sending, by the first device, a first message; - listening for a second message until the waiting time expires, wherein, shortening the waiting time by detecting a subsequent button press on the first device; - if one or more second messages have been received from only one device, entering the secure phase of the push button protocol, and - If the second message has not been received or if the second message has been received from more than one device, aborting the button protocol.

7. A device arranged to participate in a push button protocol, the device comprising a push button and a processor, the processor being arranged to: - starting a waiting time timer after detecting a first button press on said button; - listening for a first message after detecting the first button press until the waiting time expires, wherein, shortening the waiting time by detecting a subsequent button press on the first device; - if the first message is received, sending a second message; - if one or more first messages have been received from only one device, entering the secure phase of the push button protocol, and - If the first message has not been received or if the first message has been received from more than one device, aborting the button protocol.

8. The apparatus according to any one of claims 6 or 7, wherein: The first device sends a first message through more than one channel.

9. The device according to claim 8, wherein: The first device listens on more than one channel for a first message.

10. The apparatus according to any one of claims 6 to 9, wherein: The first message is a button presence notification, the second message is a button presence notification response, and the security phase of the protocol starts with the PKEX protocol from the Device Provisioning Protocol (DPP).

11. A computer program product, arranged to, when run on a processor of a device according to any one of claims 6 to 10, cause the processor to perform the method according to any one of claims 1 to 5.

Images