add bind mode

[henkwiedig]

This MR adds a bind mode to wfb_rx, wfb_tx, and wfb_tx_cmd.

The idea is to simplify the exchange of key material. A drone can have a bind button or use "three plug detection" to enable bind mode. In this mode, it accepts an unencrypted bind packet from the GS.

To enable bind mode on the drone side, wfb_rx needs to receive a SIGUSR1 signal. On the GS side, wfb_tx and wfb_tx_cmd have a new bind command, which optionally takes the key file name as an argument to send.

Caveat: Currently, only the receiving instance of wfb_rx updates its keys without requiring a restart. Other instances may still be using the old keys.

[svpcom]

Why just don't use some standard key pair (common to all users of your firmware) and use different link_id (which is integer value) for binding?

Because (for example) if you start use many drones in one place then different keys will not save you from getting alien packets and your d_err counter will be nonzero.

[henkwiedig]

Wouldn't it make more sense to offer an unencrypted mode for wfb-ng? If everyone is using the same key, then no one is really using encryption at all anyway. This would remove the hassle of exchanging keys.

[svpcom]

Encryption is a part of the wfb-ng protocol. It is used to control the integrity of the transmission and its removal will require a complete reworking of the protocol. Most modern protocols (such as wifi wpa, bluetooth, lorawan, etc.) always work only in encrypted mode. WFB-ng is used not only for DIY FPV, but also for regular robotics, where a connection failure can lead to big problems.

If it is difficult for a regular FPV user to set up a key pair, then as I said above, you can make a "standard key" in your firmware and separate different users by link_id, which is simply an integer from 0 to ~16M. link_id can be entered from the remote control (a couple of buttons will be enough), via bluetooth or encoded in a barcode. From my point of view, adding binding to the protocol greatly expands the attack vector (remember the problems with WiFi WPS).

[svpcom]

@henkwiedig

Another suggestion for easy bind:

1. Use some special "bind" link_id (and maybe keypair) and switch to it by pressing key both on drone and GS
2. After link is established then do key exchange and generate new random link_id both for drone and and GS via ip tunnel
3. After binding is complete then do synchronious switch to new settings

This will not require any changes in low-level wfb-ng protocol and could do any amount of additional steps like config sync

[henkwiedig]

That is essentially what I prototyped here: https://github.com/henkwiedig/wfb-bind. I just thought it might be a more elegant design to integrate it into wfg-ng.

I understand that there are applications requiring encryption, and I wouldn’t want to remove this functionality entirely. However, FPV is an application where encryption is not really an issue—we’ve lived without it in analog systems, and it even offers some benefits in the FPV world.

For FPV, having multiple pilots on the same channel and therefore requiring different link_ids is a dealbreaker anyway. It does make things more complicated for the end user.

The easiest approach might be to stick with a shared secret among all deployments. If someone really wants to change the keys and has the technical knowledge to do so, they are free to implement that themselves.