How vulnerable is Bluetooth for Industry 4.0? Any use cases to help get confidence?

[Riyaz]

We are building a solution for a large OEM where we have BLE tags on inventory trolleys and employees. When the trolley is empty, the BLE tag on the trolley would send a notification to the central via Bluetooth. This would then use WiFi to send the data to the MQTT server. This data would be then sent to the application server, where the decision matrix would send messages to the concerned persons/departments for further actions.

Simple??

Yes, but the OEM is concerned about spoofers, hijacking on the BLE packets and sending undesired packets. Has anyone answered this question and if yes, how?

[bjorn-spockeli]

Hi Riyaz, 

if the BLE tags are connected to the central, then you can bond the tags to the central and use the LE Secure Connections feature of Bluetooth 4.2 to encrypt the link with AES-128bit encryption. The LE Secure connections feature generates the ecryption key using the Diffie-Hellman key exchange and provides protection against man in the middle attacks, i.e. spoofing. 

 In addition you can create a whitelist on the central so that only devices that are bonded can connect to the central. Any packet from an unbonded device will be rejected. 

Best regards

Bjørn

[Riyaz]

Dear Bob,

Thank you for your kind reply.  The connection mode is not possible, as the central is more than 10 meters away from the tag. That is the reason, we are choosing RFC6238. We have successfully built the firmware to handle this. We now need to give confidence to the OEM, that there is no other threat. Is there a CE certification for this or any other way to instil this confidence in them?

regards,

Riyaz

[bjorn-spockeli]

Riyaz said:

The connection mode is not possible, as the central is more than 10 meters away from the tag.

 Establishing and maintaining a Bluetooth connection at 10 meters should be be perfectly feasible, but I understand if there are other considerations to why you have chosen advertising only. 

Riyaz said:

That is the reason, we are choosing RFC6238. We have successfully built the firmware to handle this. We now need to give confidence to the OEM, that there is no other threat. Is there a CE certification for this or any other way to instil this confidence in them?

Are you referring to threats at ship level, i.e. physical attacks or  you referring to the implementation of our Bluetooth Protocol stack?Any security threats in the Bluetooth Low Energy Protocol and their fixes with will be made public by the Bluetooth SIG, see https://www.bluetooth.com/security/

[Riyaz]

Dear Bob,

Yes, I, am referring to physical attacks like spoofing of the advertizing packets, that may result in denial of service or incorrect data.

We have resolved this by using RFC6238, but need a way to give confidence to the OEM that the system is not attackable.

regards,

Riyaz

[bjorn-spockeli]

I am afraid that we do not have any certificate covering the RFC6238 or similar solutions. We cant really comment on any encryption algorithm or solution that we have not implemented our selves. 

It is possible to set up a whitelist when a Bluetooth Low Energy central is scanning, i.e. that it will only process advertisment packets from devices who's address match an entry in the whitelist. However, if the content of the advertisment packet is encrypted and the encryption algorithm is considered safe by for instance NIST, then spoofing and hijacking should not be a concern.

The only way I see that one can avoid spoofing is to use random resolvable addresses and let the tags connect and bond with the central. The tags will then change their address regularly, making spoofing more difficult and the central would then use the Identity Resolving Key(IRK) to identify the tag from its list of bonded peers.   

Best regards

Bjørn

[Riyaz]

Dear Bob,

Thank you! that helped.

regards,

Riyaz