Bluz Security: advertising, connecting, claiming, and sendData()


#1

I’m generally trying to wrap my head around Bluz communication and security at a low level. I’m new in the BLE world so I have many questions:

  1. Out of the box, the BluzDK boots in advertising mode, periodically sending ADV_IND packets.
    – Can we control the periodicity and contents of these packages?

  2. The App scans for devices, effectively just listening for Bluetooth advertising packets.
    – Does it send any Scan Requests? Is the BluzDK configured for any Scan Responses?

  3. The user initiates a connection to the BluzDK.
    – It seems like a connection is established using the “Just Works” simple pairing method, can that be changed? Eg. requiring a pin.

  4. Upon successful connection, the App requests all available Bluetooth services, which are
    Generic Access (0x1800):
    Device Name (0x2a00): BluzDK
    … other GAP characteristics.
    Generic Attribute (0x1801)
    Customized Service (871e0223-38ff-77b1-ed41-9fb3aa142db2):
    Characteristic1 (871e0224-38ff-77b1-ed41-9fb3aa142db2): read, notify - effectively RX
    Characteristic2 (871e0225-38ff-77b1-ed41-9fb3aa142db2): read, writeWithoutResponse - TX
    – Where can we change the GAP device name in the firmware?

  5. The App then requests the BluzDK’s Particle name, Particle Id, and claim state.
    – Since these are not Characteristics, I assume they are communicated via the “RX”, “TX” Characteristics within the customized service.

  6. If unclaimed, the App requests a claim code for the user’s account on Particle, and sends it to the device.
    – Or is the device connected to the Cloud without a claim code, then just claimed via the Particle API (i.e. POST to /devices with user scoped token)?

  7. Once claimed, the App just acts as a Bluetooth to IP bridge, enabling CoAP communication with the Particle cloud.
    – How is the data to be forwarded (CoAP packets) separated from control data (e.g. requests for Particle Id)? Via headers?

  8. If the App receives / transmits data with a special packet header (0x04) then it is treated separately from the CoAP stream, and considered as local communication. (This is how sendData() works.)

Please correct any of my above assumptions.

Also, I’m generally confused as to how we should prevent another device from hijacking the connection to the BluzDK on reboot or disconnect.

I understand that the connection to the Particle cloud is encrypted, and variable reads + function calls are secured via Particle’s token auth system. So becoming a man-in-the-middle, or otherwise accessing functions/variables would be very tough.

But what about the process of giving the BluzDK a new Particle claim code, can that be spoofed?

Also, it seems like sendData() is (i.e. write to 871e0225-38ff-77b1-ed41-9fb3aa142db2 with packet header 0x04) is totally open to the world. If I were to use it for essential commands, I would need to implement my own security, or, at the very least, change how the BLE connection forms. Correct?


#2

Wow, long list! Let me try and take this one by one:

  1. At the moment, not from the Web IDE but you can change anything you want with local compiling. This will be opened up in future releases, or you can local compile now and change it to whatever you would like
  2. There is no Scan Request or Response in BLE. When not connected, bluz sends out advertising packets that the centrals (gateways) listen for. You can turn off these advertising packets on bluz if you like.
  3. Correct. Just as before, this cannot currently be changed in the Web IDE but you could change anything you like with local compiling.
  4. All correct. We will allow adding more services characteristics in a future release, or you can do it from local compile for now.
  5. Correct
  6. There isn’t a claim code, the Particle cloud just associates a device ID to a specific account. Any device can connect to the cloud, it doesn’t have to be claimed, but a device must be claimed before you can send function calls and all other Particle-y stuff
  7. Correct, we used headers. There are separate ones for different “services”, just a name we use in the firmware. There is one for the cloud stuff, one for polling info like Device ID, and one for local communication
  8. Correct

As there is no claim code, this cannot be spoofed. It is true that any Bluetooth LE central could connect to bluz and hijack it, but without specific code on bluz to listen for local communication, it wouldn’t do anything. After about 45 seconds, bluz would automatically disconnect anyway. As you can’t possibly know the public clouds private key, there wouldn’t be a way to spoof the Particle cloud and hop in between either. So it would be near impossible to hijack the device and pretend like you are the cloud.

Yes, local communication is very exposed at the moment. BLE encryption in general, however, is not very secure and has been shown to be vulnerable. If you are looking at a super-secure system, it is better to use the Particle cloud or roll your own security on top of BLE.


#3

Thanks for the speedy reply @eric. That should let me progress with development!

My only concern is not being able to use a claim code. We’re migrating to Particle’s recommended two-legged auth. Which goes:

  1. Our server creates a Customer in our Org,
  2. Our server retrieves/returns a scoped token for that Customer,
  3. Customer uses that scoped token to generate a Product claim code,
  4. Customer passes that claim code to the device,
  5. Next time the device connects to cloud, it does so with the claim code, and upgrades to most recent Product firmware.
  6. Customer uses scoped token for subsequent cloud calls to the device.

If I can’t pass a claim code to the device, I need to unclaim it from our testing account prior to handing it over to the Customer. If ever the device transfers ownership, I also need to unclaim it from the previous Customer. (Since claiming via the REST requires the device be unclaimed.)

I like Particle’s “physical possession implies ownership” paradigm. It fits our products well and I would like to stick to it. Is there any way this could be accomplished on Bluz?


#4

Let me check on this. I really haven’t spent a lot of time looking into this method, but it should certainly be possible.


#5

Hi @eric,
I have changed the target name from Bluz DK to “my device” name in platform/MCU/NRF51/SPARK_Firmware_Driver/src/hw_gateway_config.c and changed device name from Bluz DK to “my device” name in platform/MCU/NRF51/SPARK_Firmware_Driver/src/hw_config.c.

And then run make and flashed bootloader.hex, softdevice.hex, system_part1.hex and myapp.hex but there is no changes in the name(when it is advertising, the device name is still Bluz DK)

Please help :slight_smile:
Thanks


#6

Issue solved! :slight_smile:

Is it possible to put a pin as described in point-3? Please help me for this issue.


#7

I am not sure I know what you mean by point 3? Do you mean changing the security type of the link?

Again, we didn’t implement this because BLE security is not secure. Also, it would interfere with our gateways. You can certainly change the system firmware to do this, if you need it, but we don’t have any plans to add this in the near future.