Raspberry Pi – Location Aware Media Server – Pairing

As mentioned in the post Raspberry Pi Location Aware Media Server I mentioned a new project I am embarking on. This post is to document my current process and thinking regarding the pairing process for the beacon Pi’s and the server Pi and for the initial setup to be carried out.

This post will reflect my current plans therefore will change over time. Where I have decided against a certain approach I will either create a new post specifying why or I will update this post giving reasons depending on the most appropriate approach.

The following are the main steps that will take place for a basic handshake to take place.A more detailed description is listed below.

Hardware Required

Server Raspberry Pi contains the following:

  • Bluetooth chip (already built in)
  • Bluetooth dongle (if the server also acts as a beacon)
  • Wireless access point
  • Button hooked up to GPIO

Beacon Raspberry Pi contain the following:

  • Bluetooth chip (already built in)
  • Button hooked up to GPIO
  • Wireless chip (already built in)

Basic Pairing Steps

The following are the steps for pairing:

  1. User presses the button on the server Raspberry Pi.
  2. User presses the button on the beacon Raspberry Pi.
  3. Script pairs devices together.
  4. Server sends payload to beacon with setup instructions.
  5. Server disables Bluetooth.
  6. Beacon connected wirelessly to server.

Detailed Pairing Steps

  1. When the user presses the button on the server Raspberry Pi this will trigger a script to setup the Bluetooth connection. The setup would include setting the broadcast name and a pin (this would need to remain static as the beacon would need to know this unless we do a no secured Bluetooth connection, will need to double check this). The script would then enable the Bluetooth on the server ready for the beacon.
  2. When the beacon button is pressed a script triggers to tell the beacon to prepare to pair with another device.
  3. Beacon pairs with server using a pre known broadcast name and pin. If the paring does not occur within 2 minutes both server and beacon disable the attempt. The server would disable the Bluetooth adapter.
  4. On successful pairing the server sends a payload to the beacon. This payload simply has a list of required modules that can be obtained through apt-get, the network name and password for the wireless and any other ad hoc details required for the further steps. No runnable scripts would be contained within the payload.
  5. Server disables the Bluetooth adapter limiting connection to it.
  6. Beacon connects to wireless with supplied credentials. Wireless used for further communication.

Security Considerations

In the hardware details I mention that if the server acts as a beacon it requires a Bluetooth dongle. This is to enable to have 1 that properly allows pairing for the initial setup. The Bluetooth used for beaconing would not allow proper pairing. This will help limit the methods of connection to the server thus enabling an easier method of securing the server.

The buttons would limit Bluetooth connection for a limited period of time. This limits the possibility of other devices connected.

The Bluetooth pairing is relying on a known pin and Bluetooth name. This raises the possibility that these would become known. At present I do not see a way around this so the limited amount of time it is active is key. If the details are not known then new beacons would be difficult to setup.

Upon pairing the beacons receives a payload from the server. This would contain the package names required for the system to work. This would also contain the wireless name and password allowing the details to be customer and changeable on the server (although a method would be required for beacons to be updates as they change). A potential downside of this however is that if a rogue devices connects via Bluetooth it will receive the WiFi details and will be harder to get rid of. A method would be required for blocking MAC address of devices that are unknown in the control panel that will be built.

Potential Alternative Flow

  1. Beacon to have a paining token shipped with it.
  2. User logs onto control panel and enters this pin which also enables Bluetooth.
  3. Beacon and server connect using the supplied token over Bluetooth.
  4. Once paired, server sends payload to beacon with setup instruction.
  5. Bluetooth disconnects and disables on server
  6. Beacon connects wirelessly.

This approach would help limit the possibility of an unknown device connecting as it would be a non predictable pin used to connect to Bluetooth.

Is there anything I have missed or any security implications not addressed. Would the added overhead of the alternative flow be worth the added security?

Tell us your thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.