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:
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?
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?
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.
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?
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.
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
/deviceswith user scoped token)?
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?
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?