Push Button Protocol

Abstract

A method and apparatus are provided for executing a push button protocol between a first device and a second device. The method includes, by the first device, transmitting a first message after receiving a first button press, listening for a second message until either a waiting time elapses or a third button press is received, whichever is earlier, proceeding to a secure phase of the push button protocol if one or more second messages are received from only one device, and aborting the push button protocol if no second message is received or if second messages are received from more than one device. In another case, the method includes, after receiving a first button press, listening for a first message until either a waiting time elapses or a third button press is received, whichever is earlier, transmitting a second message by the first device if the first message is received, proceeding to a secure phase if one or more first messages are received from only one device, and aborting the push button protocol if no second message is received or if second messages are received from more than one device.

Description

Technical Field

[0001] The present invention relates to an apparatus and method for use in a wireless network, particularly a wireless network compliant with the IEEE 802.11 standard family.

Background Art

[0002] FIG. 1 depicts a wireless network 1 including a first device 2 and another device 3. The first device 2 has a central function and may be, for example, an access point (AP), a hub, or a gateway device. The first device 2 is hereinafter referred to as an AP for simplicity, although other types of devices are also possible in practice. A user (not shown) wishes to add two more devices to the network 1, namely a complex device 4 (represented here as a computer) and a simple device 5 (represented here as a toothbrush). Devices such as the simple device 5 often do not have a practical user interface (UI) other than perhaps lights and are thus often referred to as "headless" devices. The AP 2 has a processor 6, and the simple device 5 has a microcontroller and a small non-volatile memory 7, and a button 8 used to reset the simple device 5. There is also a third device 9.

[0003] In some wireless network standards, one device can configure another device to establish a connection and communicate. This eases the burden of the task of adding or registering new devices to the network in that the user no longer has to perform manual input.

[0004] Diffie-Hellman (see reference [DH]) is a well-known technique for establishing a secret key between two parties such that the communication between the parties for establishing the secret key does not disclose any information about the established secret key to a third party. Each of the two parties uses its own public / secret key pair and exchanges the public keys with each other. Each party can calculate the secret key using its own secret key, the other party's public key, and optionally, other information such as a nonce (random number) from each party. Each party can generate a new key pair or reuse an old key pair each time it executes Diffie-Hellman.

[0005] A commissioning protocol such as the Wi-Fi Alliance's Device Provisioning Protocol (DPP) (see reference document [DPP]) uses Diffie-Hellman to establish a secret key between two devices, a DPP Enrolllee who wishes to be configured and a DPP Configurator who can configure the DPP Enrolllee, enabling these devices to access a DPP-compliant network and set up the DPP-compliant network as an access point (AP) (see reference document [802.11]).

[0006] When performing Diffie-Hellman over a network, a device that receives a public key for performing Diffie-Hellman does not know from which device this public key is. This can be exploited by an attacker in a so-called man-in-the-middle attack. The attacker E may pretend to be the actual device B that device A wants to connect to. The attacker E performs Diffie-Hellman with device A and establishes a secret key Kae with device A. Similarly, the attacker pretends to be device A to device B and establishes a secret key Kbe with device B. When a message arrives from either device A or B, the attacker decrypts the message with one secret key, encrypts it with the other secret key, and forwards it to the other device. In this way, devices A and B do not notice anything strange in their communication, except for some extra delay. When checking the communication by sending the same information via another communication method and comparing the results, they do not notice any tampering of their communication. However, the attacker has complete knowledge of what is being communicated. Summary of the Invention Problems to be Solved by the Invention

[0007] Therefore, it is desirable to provide a push-button protocol for addressing these problems. Means for Solving the Problems

[0008] A method for executing a push-button protocol between a first device and a second device is provided. The method includes the steps of: transmitting, by the first device, a first message after receiving a first button press; listening for a second message until the expiration of a waiting time, where the waiting time is shortened by detection of a subsequent button press on the first device; and proceeding to a secure phase of the push-button protocol if one or more second messages are received from only one device, or aborting the push-button protocol if no second message is received or if second messages are received from more than one device.

[0009] Also provided is a method for executing a push-button protocol between a first device and a second device. The method includes the steps of: listening, by the first device, for a first message after receiving a first button press until the expiration of a waiting time, where the waiting time is shortened by detection of a subsequent button press on the first device; transmitting, by the first device, a second message if the first message is received; and proceeding to a secure phase if one or more first messages are received from only one device, or aborting the push-button protocol if the first message is not received or if first messages are received from more than one device.

[0010] Additional button presses can improve both the security and reliability of the protocol. This is because the waiting time (i.e., the walking time) is shortened, thus limiting the window during which a rogue device can attempt to connect by transmitting messages to or listening for messages from one or both of the two devices that the user is actually trying to set up and connect. However, the shortening of the walking time is only performed if the user can confirm that this is appropriate, so that the likelihood of the protocol completing successfully is well maintained.

[0011] In one aspect, a first device can send a first message via two or more channels.

[0012] In one aspect, a first device can listen for a first message on two or more channels.

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

[0014] In one aspect, the first message is a push button presence announcement, the second message is a push button presence announcement response, and the secure phase of the protocol starts with the PKEX protocol from the Device Provisioning Protocol (DPP).

[0015] A device configured to participate in a push button protocol is provided. The device has a push button and a processor, and the processor starts a waiting time timer after detecting a first button press on the push button, the first device sends a first message after detecting the first button press, listens for a second message until the expiration of the waiting time, the waiting time is shortened by detecting a subsequent button press on the first device, and proceeds to the secure phase of the push button protocol when one or more second messages are received from only one device, and aborts the push button protocol when the second message is not received or when the second message is received from two or more devices.

[0016] Also provided is an apparatus configured to participate in a push button protocol. The apparatus has a push button and a processor, which starts a waiting time timer after detecting a first button press at the push button, listens for a first message after detecting the first button press until the expiration of the waiting time, the waiting time being shortened by detecting a subsequent button press at the first apparatus, and when the first message is received, transmits a second message, and proceeds to a secure phase of the push button protocol when one or more second messages are received from only one apparatus, and is configured to abort the push button protocol when the first message is not received or when the first message is received from two or more apparatuses.

[0017] Also provided is a computer program product configured to cause a processor to execute the method described herein when executed on a processor of an apparatus as 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.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Best Mode for Carrying Out the Invention

[0019] In the following description, the same reference numerals refer to like elements.

[0020] FIG. 2 shows a flow of a device control setting method according to an embodiment in which one device such as the third device 9 or the AP 2 in FIG. 1 is set and can be connected to another device such as the complex or simple devices 4, 5 in FIG. 1. The third device 9 in FIG. 1 can set other devices such as the complex or simple devices 4, 5 in FIG. 1 to enable other devices to connect to the AP 2. The third device 9 and the devices 4, 5 are according to the embodiment. As an example, the case of the simple device 5 will be described. Although much of this description provides examples that include a network having a device such as the AP 2, it should be understood that this process may function in a peer-to-peer situation.

[0021] One way for a configurator and an enrollee that execute Diffie-Hellman to confirm that the user is really on the device intended by the user, such as at the start of a setting protocol as defined by [DPP] or [WPS], is the push-button method as described in section 5.8 "Push-button PKEX-based" of [DPP] or section 11 "Pushbutton Configuration" of [WPS].

[0022] The push-button protocol is used in many other networks such as the network to which the devices are paired. The push-button protocol can be summarized as follows. The user desires that two wireless devices be securely involved in a protocol, for example, a configurator of one of the devices configures an enrollee of the other device to be able to access a specific network. If the purpose is pairing, the process is similar in important aspects.

[0023] In S1, the user presses a button on a first device, which is one of these devices (first button press). At this point, it doesn't matter whether the first device is a configurator or an enrollee. Depending on the details of a specific push button protocol, the first device starts listening for a first push button message indicating that another device wants to participate in executing the push button protocol, or starts sending a first push button message indicating that the first device wants to participate in executing the push button protocol. In FIG. 2, for simplicity, the case where the first device sends a message is shown. The first device does this only for a specific amount of time, i.e., the walking time. In S2, the user presses a button on a second device (second button press). The two devices may be placed relatively far apart within a house. For example, there may be a Wi-Fi access point (AP) with a configurator function underground and a smart water heater using Wi-Fi for connection to the power company in the attic, thus the term "walking time". Due to this distance, the walking time in WPS is set to 120 seconds, and in DPP, it is called the first listening period and is set to 100 seconds.

[0024] After the second button press, the second device starts sending a first push button message indicating that it wants to participate in executing the push button protocol, or starts listening for a first push button message indicating that another device wants to participate in executing the push button protocol, depending on the details of a specific push button protocol. Also, the second device does this only for a specific amount of time, which is the same as or different from the walking time of the first device.

[0025] The device that starts sending the first push button message is called the initiator in this specification, and the device that starts listening for the first push button message is called the responder. The initiator can be the first or the second device, and the responder can be the second or the first device.

[0026] In [DPP], the first message is a push button presence announcement, the second message is a push button presence announcement response, where the device referred to as the initiator is called an enrollee in [DPP], and the responder is called a configurator in [DPP].

[0027] In [WPS], the first message is a probe request having a Device Password ID and a WSC IE (Wi-Fi Simple Configuration Information Element) (see, for example, section 11.3 of [WPS]), the second message is a probe response indicating a Selected Registrar (WPS name for configurator) having a PBC (Pushbutton configuration) Device Password ID and a WSC IE (see section 11.3 of [WPS]), what is called the initiator in this application is called an enrollee in [WPS], and what is called the responder in this application is called a registrar in [DPP]. The registrar can be regarded as a configurator and is usually arranged in a Wi-Fi AP.

[0028] Depending on the details of a particular push button protocol, the initiator traverses all the channels supported to send the first message while the responder listens on one channel, or the responder traverses all the channels supported to listen for the first message while the initiator sends the first message on one channel.

[0029] In [DPP] and [WPS], the initiator traverses all the channels while the responder listens on one channel.

[0030] When the responder device is unknown, as in the case of [DPP], the first message can be sent to the broadcast address. In [WPS], the enrollee, and thus the initiator, can find out which registrar is active by checking whether the beacon signal of the AP supporting the registrar incorporates a Selected Registrar flag set to TRUE.

[0031] If the responder does not receive the first message within the walking time, it aborts the push-button protocol and the execution of that protocol fails. If the responder receives the first message from multiple devices within the walking time, it aborts the push-button protocol and fails in the execution of that protocol. This is because in the latter case, there are two or more potential candidates for further involvement in the protocol, but the responder does not know which of these is the intended one. The intended initiator is called the intended initiator and other initiators are called unauthorized initiators. The protocol continues only if the responder receives the first message from one initiator.

[0032] Upon receiving the first message, the responder responds with a second message. Exactly when that occurs depends on the particular push-button protocol. It can be, for example, immediately after reception or after cycling through all channels and detecting no unauthorized initiators.

[0033] Similar to the case of the responder described above, when the initiator does not receive a second message within the walking time, it aborts the push button protocol and the execution of the protocol fails. When the initiator receives a second message from two or more devices within the walking time, it aborts the push button protocol and fails to execute the protocol. This is because in the latter case, there are two or more candidates that are further involved in the protocol, but the initiator does not know which of these is the intended one. The intended responder is called the intended responder, and the other responders are called unauthorized responders. The protocol continues only when the initiator receives a second message from one responder.

[0034] The push button protocol, or simply the protocol described above, consists of two phases. The phase in which the first and second messages are exchanged can be called the discovery phase of the protocol. This is completed at S3. After the discovery phase is successful, the secure phase of the protocol begins, and the two devices can securely participate in a protocol such as a bootstrap protocol like the PKEX protocol of [DPP], or a configuration protocol such as all the messages from "Authentication Request" to "EAP-Response (Done)" of the Figure 18 - PBC message exchange of [WSC]. This part ends at S4(END). This process is represented in Figure 2 as "secure exchange".

[0035] The problems with push-button protocols as described above are that they require at least a walking time and thus take about two minutes to complete. This is a very long waiting time for the user, especially when both devices are within reach of the user's hand and the buttons of those devices can be pressed within seconds of each other. On the other hand, the walking time has to be long enough to enable the user to move between devices in most situations. During this time, the devices are exposed to attacks. Therefore, this method has drawbacks.

[0036] The discovery phase of the protocol can be shortened by having the responder reply immediately to the first message it receives or, at the latest, after passing through all supported channels again, and considering the walking time to have ended if it has not received the first message from multiple devices and proceeding to the secure phase of the protocol. This is enhanced by requiring the initiator and / or responder to listen for the first message again before their buttons are pressed and, for example, by maintaining a list of these messages to which it can return during at least the walking time. However, the inventor has recognized that this solution has drawbacks. When the responder receives the first message, the responder does not know whether this first message is from the intended device or from an unauthorized device. Also, if the responder proceeds to and ends the secure phase of the protocol before the walking time actually ends, the user may be "walking" to the intended initiator to perform the first button press on the responder and still perform the second button press. Also, a sudden end to the discovery phase can occur as a result of the responder receiving a message from another (possibly unauthorized) device without starting the secure phase. In either case, the message from the intended initiator arrives too late at the responder, resulting in the protocol being aborted unnecessarily.

[0037] Figure 3 shows the flow according to the embodiment. This flow is similar to the flow of Figure 2, and similar elements will not be described again. After the user presses the second button, that is, after the user presses the button on the second device, the user returns to the first device and presses that button for the second time at S3a. This button press is called the third button press. In contrast to what is defined in [WSC], this third button press means that the walking time has passed for the first device, and the first device can proceed to the secure phase of the protocol, that is, proceed to S4. Optionally, the user presses the button for the second time on the second device (referred to as the fourth button press) to notify the second device that the walking time has ended.

[0038] In [WPS], pressing the third or fourth button on the device indicates to the device to newly start the push button protocol, and it should be noted that this is a very different action from what is described in this specification.

[0039] Similarly, when the user presses a button on the initiator and the initiator is allowed to proceed to the secure phase of the protocol when it receives a second message before the walking time has passed, just depending on not receiving a second message from another device during a certain period before the button is pressed, it is impossible to know whether the received second message is from the intended device or from an unauthorized device. If the initiator proceeds to and ends the secure phase of the protocol before the walking time actually ends, the user may be "walking" to the responder (the intended responder) in order to still execute the first button press and then the second button press on the initiator. The message from the intended initiator arrives at the responder too late.

[0040] When the first device (responder or initiator) receives a third button press from the user, the first device knows that the second device had the time to send a first message (if the second device is the initiator) or a second message (if the second device is the responder). Optionally, to increase the certainty of this decision, after the third button press, if the first device has not received the first or second message from more than one device at least since the first button press, before proceeding to the secure phase of the protocol, it cycles through all the channels it supports. Even if the first device does not receive a third button press, if the walking time has elapsed, it can proceed to the secure phase of the protocol.

[0041] The advantage is that, rather than receiving a third button press, the first device can proceed to the secure phase of the protocol earlier than the walking time while ensuring that it is cooperating with the intended second device and not involved with some other (potentially malicious) unauthorized device. Another advantage is that the shortening of the walking time is done only by the user's positive action rather than letting the device decide, ensuring that the user has time to actually press the buttons of each device.

[0042] However, the second device that receives the first message (when it is the responder) or the second message (when it is the initiator) after the second button press cannot proceed to the secure phase of the protocol based on knowing for sure that the message is from the first device it was intended for. It is considered sufficient that the first device is ready to start the second phase of the protocol, and it is not a problem that the second device does not yet know for sure. However, as an option, it may be advantageous to add yet another button press. After the third button press on the first device, if the user presses the button a second time on the second device (i.e., the fourth button press), the second device also knows that the first device had time to send its first or second message. This fourth button press is not shown in Figure 3. If the fourth button press is used, it is this fourth button press, rather than the third button press as S3a, that triggers the start of the second phase.

[0043] As an option, to increase the certainty of this determination, after the fourth button press, the second device, if it has not received the first (if it is the responder) or second (if it is the initiator) message from a plurality of devices at least since the second button press, will cycle through all the supported channels before proceeding to the secure phase of the protocol. In either case, if the walking time ends and the second device does not receive the fourth button press, it can proceed to the secure phase of the protocol.

[0044] At first glance, this may seem counterintuitive in that it can be regarded as a burden on the user if the user has to go to the second device to perform a second button press, return to the first device for a third button press, and then go back to the second device again for a fourth button press. However, if the distance between the two devices is such that the time to travel between them is longer than the protocol's walking time, the user does not need to perform a fourth button press or a third and fourth button press. This is because the protocol ends before the user can execute a third or fourth button press. However, the third and fourth button presses do not burden the user when the devices are in close proximity to each other, while the time to execute the protocol is significantly shorter than the walking time in this case, which is advantageous for the user. Furthermore, even if the user has to change location to execute a third button press and possibly a fourth button press, the additional security and reliability of the protocol would justify this additional burden.

[0045] It should be understood that the examples used in this description of the push button protocol use Wi-Fi, but the push button protocol and the improvements proposed in this application can use any wireless technology such as Bluetooth [BT], ZigBee, etc.

[0046] Figure 4 represents a device according to an embodiment. Device 40 has a processor 41, an optional transceiver 42, a push button 43, and an optional input / output port 44. Device 40 can also have a storage unit (not shown) for storing computer program code. Input / output port 44 can be used to connect the device to an external transceiver when transceiver 42 does not physically exist within device 40. The transceiver is configured to transmit and receive messages according to the relevant wireless technology.

[0047] FIG. 5 represents a storage medium 50 that, when installed in the device 40, can hold computer code for causing the device 40 to execute the method according to the embodiment. The storage medium 50 may be part of the device 40 or may be a separate storage device such as a data carrier or a remote server.

[0048] In summary, a method for executing a push button protocol between a first device and a second device includes the steps of: the first device transmitting a first message after receiving a first button press; listening for a second message until either the expiration of a waiting time or the detection of a subsequent button press on the first device, whichever occurs first; proceeding to a secure phase of the push button protocol if one or more second messages are received from only one device, and aborting the push button protocol if no second message is received or if second messages are received from more than one device.

[0049] There is also a method for executing a push button protocol between a first device and a second device. The method includes the steps of: listening for a first message after receiving a first button press until either the expiration of a waiting time or the detection of a subsequent button press on the first device, whichever occurs first; the first device transmitting a second message if the first message is received; proceeding to a secure phase if one or more first messages are received from only one device, and aborting the push button protocol if no first message is received or if first messages are received from more than one device.

[0050] By pressing an additional button, both the security and reliability of the protocol can be improved. This can reduce the waiting time (i.e., the walking time), and limit the window for an unauthorized device to attempt a connection by sending a message to or listening for messages from one or both of the two devices the user is actually attempting to set up and connect. However, the reduction in walking time is only executed if the user can confirm that this is appropriate, and as a result, the likelihood that the protocol will complete successfully is maintained well.

[0051] The first device can send a first message via two or more channels.

[0052] The first device can listen for the first message on two or more channels.

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

[0054] The first message may be a push button presence announcement, the second message may be a push button presence announcement response, and the secure phase of the protocol starts with the PKEX protocol from the Device Provisioning Protocol (DPP).

[0055] There are devices configured to participate in a push-button protocol. The device has a push button and a processor, which starts a waiting time timer after detecting a first button press on the push button, and the first device transmits a first message after detecting the first button press, listens for a second message until either the expiration of the waiting time or the detection of a subsequent button press on the first device, whichever is earlier, and proceeds to the secure phase of the push-button protocol if one or more second messages are received from only one device, or aborts the push-button protocol if the second message is not received or if the second message is received from more than one device.

[0056] There are also devices configured to participate in a push-button protocol. The device has a push button and a processor, which starts a waiting time timer after detecting a first button press on the push button, listens for a first message until either the expiration of the waiting time or the detection of a subsequent button press on the first device, whichever is earlier, and transmits a second message if the first message is received, and proceeds to the secure phase of the push-button protocol if one or more second messages are received from only one device, or aborts the push-button protocol if the first message is not received or if the first message is received from more than one device.

[0057] A computer program product is also provided that is configured to cause a processor to execute the methods described herein when executed on a processor of a device as described herein.

[0058] Aspects of this embodiment may be a set of computer program instructions stored on a computer-readable storage device that can be executed by a computer, and may be implemented in a computer program product. The instructions may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), or Java classes. The instructions may be provided as a complete executable program, a partial executable program, a modification (e.g., update) to an existing program, or an extension (e.g., plugin) to an existing program. Further, a portion of the processing of the present invention can be distributed among multiple computers or processors.

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

[0060] The following can be used as references: [802.11] IEEE Computer Society, “IEEE Standard for Information Technology- Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” (IEEE Std. 802.11-2016), December 2016. [BT] Bluetooth Core Specification, v5.0, https: / / www.bluetooth.com / specifications / bluetooth-core-specification / bluetooth5, December 2016. [DH] Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEE Transactions on Information Theory, 22 (6): 644-654. [DPP] Proposal to add Push Button bootstrapping to Device Provisioning Protocol - 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 push-button protocol between a first device and a second device, The first device, after receiving a first button press, transmits a first message; A step of listening for a second message until the waiting time expires, wherein the waiting time is shortened by the detection of a subsequent button press on the first device, The first device, if it does not receive the second message, or if it receives the second message from multiple devices, terminates the push-button protocol. The second device listens for the first message after receiving the first button press until the end of the waiting period, wherein the waiting period is shortened by the detection of a subsequent button press on the second device. The second device, when it receives the first message, sends a second message; The steps include: proceeding to the secure phase when one or more first messages are received from only one device and the waiting time has ended; The second device then terminates the push-button protocol if it does not receive the first message or if it receives the first message from multiple devices. A method of having.

2. The method according to claim 1, wherein the first device transmits a first message on a plurality of channels.

3. The method according to claim 1, wherein the first device listens for a first message on a plurality of channels.

4. The method according to claim 1, wherein the first message is a push button presence announcement, the second message is a response to the push button presence announcement, and the secure phase of the push button protocol is initiated by the PKEX protocol from the Device Provisioning Protocol (DPP).

5. A device configured to participate in a push-button protocol, The device has a push button and a processor, and the processor is After detecting the first button press on the push button, a waiting time timer is started. After detecting the pressing of the first button, the system listens for the first message until the waiting time, which is shortened by detecting a subsequent button press on the push button, expires. If the first message is received, send the second message. If one or more first messages are received from only one device and the waiting time expires, the process proceeds to the secure phase of the push-button protocol. The push-button protocol is terminated if the first message is not received, or if the first message is received from multiple devices. A device configured in such a way.

6. The apparatus according to claim 5, which transmits a first message over multiple channels.

7. The apparatus according to claim 5, which listens for a first message on multiple channels.

8. The apparatus according to claim 5, wherein the first message is a push button presence announcement, the second message is a response to the push button presence announcement, and the secure phase of the push button protocol is initiated by a PKEX protocol from a Device Provisioning Protocol (DPP).

9. A computer program executed by the processor of the apparatus according to any one of claims 5 to 8, which causes the processor to perform the method according to any one of claims 1 to 4.

Images