Bluetooth Security

[windows97]

Would like to request if possible that you could have a password or pincode, maybe even a qr code if possible to pair bluetooth devices to Moode. If I have BlueZ activated all time I guess anyone can pair without my permission? Would still like it to be quite straightforward without needing to access the Moode interface if possible.

If it's that this already exists, I would be happy to know how to activate it.

Thanks

[Tim Curtis]

Given Bluetooth's range limitations of around 30 ft under ideal conditions, whats the usage scenario where pin code access is needed?

[betarho]

Given Bluetooth's range limitations of around 30 ft under ideal conditions, whats the usage scenario where pin code access is needed?

The usage scenario is any situation where other people actually are inside the Bluetooth range.
An example: neighbours living in apartments located in the same building.
Another one: a device could be used in a store, so anyone visiting the store could have access to it.

[Tim Curtis]

Those are legit usage scenarios but prolly not too common for moOde users.

In any case I'll add to the TODO list to investigate but it will require a dev with more Bluetooth expertise than I have to figure out whats needed to enable/disable PIN code authentication.

[jakste]

+1 on this request. We use moode in a training facility and would like to limit the connections to the once knowing the code.

Thanks for all your great work!

[Tim Curtis]

I had this text file from a while back. I don't know if it still applies but maybe someone can test it out and report back.

Code:

There are two useful ways of running the agent:

1. sudo /var/www/daemon/blu_agent.py --agent --disable_pair_mode_switch --pair_mode

This simply runs the agent in such a way that it will accept any and all pairing requests and authorise them.

2. sudo /var/www/daemon/blu_agent.py --agent

This will start the agent in a mode that will reject all pairing requests by default. However, at the same time, it registers itself as a dbus service and waits to be instructed to enter pairing mode.

This will activate pairing mode for 30 seconds.

sudo /var/www/daemon/blu_agent.py --pair_mode --timeout 30

The idea of the second mode is, that pairing is disabled by default, but the gui offers a "PAIR" button to temporarily activate it - similarly how many commercial bluetooth devices do it.

It is also possible to instruct a running agent to activate pairing indefinitely (don't give a --timeout) or to disable pairing (--disable_pair_mode). Thus, the state of a running agent can be controlled completely without needing to restart it.

My suggestion would be to integrate the agent in such a way that it always runs. The user can then choose whether pairing should be always open or only open upon pressing the "PAIR" button. The gui would then change the mode of the running agent accordingly.

Until such time that the gui supports this, option (1) might be used as a default to open enable pairing for all.

If you launch the agent from a start up script, you might want to add --wait_for_bluez. The reason is, that it takes quite a while until buetoothd is available after system boot. With this option, the agent will retry to make the dbus connection instead if failing with an error.

/etc/dbus-1/system.d/moode.conf

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

<!-- ../system.conf have denied everything, so we just punch some holes -->

<policy user="root">
  <allow own="org.moodeaudio.bluez.agent"/>
  <allow send_destination="org.moodeaudio.bluez.agent"/>
  <allow send_interface="org.moodeaudio.bluez.agent.PairMode"/>
</policy>

<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
  <allow send_destination="org.moodeaudio.bluez.agent"/>
</policy>

<policy at_console="true">
  <allow send_destination="org.moodeaudio.bluez.agent"/>
</policy>

<!-- allow users of lp group (printing subsystem) to
     communicate with bluetoothd -->
<policy group="lp">
  <allow send_destination="org.moodeaudio.bluez.agent"/>
</policy>

<policy context="default">
  <deny send_destination="org.moodeaudio.bluez.agent"/>
</policy>

</busconfig>

[jakste]

A physical paring button could work, both then for blocking the neighbours and limiting the once that connects in the training facility (if button is not generally available)

Like this wall button: https://audac.eu/eu/products/d/wp220---u...80-x-80-mm

[jakste]

[jakste]

The bt-agent in bluez-tools support the PIN setup and also with the capability set to NoInputNoOuput you can get a secure (if wanted) and smoooth pairing. 

And to be able to repair a device, without manually deleting it from the device, you can add this configuration to enable reparing. Even more smooooth 

Code:

sudo nano /etc/bluetooth/main.conf


# Specify the policy to the JUST-WORKS repairing initiated by peer
# Possible values: "never", "confirm", "always"
# Defaults to "never"
JustWorksRepairing = always

[Tim Curtis]

Thats good info. Maybe a dev will become interested in contributing the modifications.