Hi Christian, Den fre 14 aug. 2020 kl 11:21 skrev Christian Seifert <christian.seifert@xxxxxxxxxxxxxxxxx>: > > Hello, > > i am trying to implement a communication channel that uses BLE Security > Mode 2 Lvl 1 or 2. Both participants that need to communicate are > Raspberry Pi's running Raspberry Pi OS and BlueZ as Bluetooth Stack. The > data i want to send is already encrypted which makes Data Signing > interesting for me. > > Does BlueZ Support BLE Security Mode 2 Lvl 1/2 and if yes how can i > access the functionality? > > Furthermore in my research to find the answer for this question i always > seemed to come across Security Mode 3 mentioned in combination with > BlueZ. Does this simply refer to Security Mode 1 Lvl 3? > > In order to find an answer for this question: I searched the web > rigorously / Tried to find an answer in forums / Read the Documentation > / Tried to read the source code / Checked the archives > > As i found nearly nothing regarding this topic my last resort is to ask > this E-Mail Chain and i would be extremely gratefull if someone would be > able to answer my question or tip me off into the right direction. > > Thank you very much for your time and help in advance! > > Best regards, > Christian Seifert > > PS: Please excuse my poor Translation attempts as English is not my > first language. I will gladly try to rewrite any confusing or misleading > parts in my message if pointed out! I have worked with BLE for around six years and I've never heard of anyone using security mode 2. It seems like it's one of those "wouldn't-it-be-nice-to-have" when they designed this many years ago, without understanding the idea is quite bad when security mode 1 exists which is superior. There are not many benefits of using this over security mode 1. There are more cons: - Data is not being encrypted, only signed. - There's only one single kind of ATT packet that can be signed, the "Signed Write Command", which is then used by GATT "Signed Write Without Response". This means that no read/write requests, notifications/indications or service discovery can be signed. It's therefore not possible to sign anything in the direction from a GATT server to a GATT client. - The signature consists of a 8 bytes CMAC signature followed by a 32-bit message counter. You can therefore only send up to 12 bytes shorter packets for a given MTU. - The signature counter must be updated and stored on flash after every message, and must be preserved across reconnections and reboots. For embedded devices with a limit of write-erase cycles this could potentially be a huge issue. With security mode 1 this doesn't happen as the link layer packet counter is per connection and direction, and can therefore be stored in RAM. - A "MITM hacker" could potentially receive a signed message, disconnect from the sender, and a few days later connect to the intended receiver and deliver the message, without the receiver noticing it has been delayed such a long time (assuming it didn't get any packet with higher counter in the meantime). - Packets can intentionally or unintentionally be dropped, without the receiver noticing that there are missing packets (assuming the Bluetooth stack doesn't expose the counter to the "application"). - It requires a specific API for the application to use (signed writes). With security mode 1 it's the lower layer that encrypts and signes everything and your GATT application can be the same regardless if you're unencrypted or encrypted. - If you implement this in a GATT server and the GATT client doesn't support signed writes, you can't really know or ask the GATT client if it supports signed writes. Even though the CSRK might be transferred during bonding, you can't know if signed writes are actually supported (yes many bluetooth stacks are stupidly made like this). The only benefit as I see it is that it requires 2.5 less round trips than setting up AES-CCM as in security mode 1. Generally the support in different Bluetooth stacks doesn't seem to be that good. For example Nordic Semiconductor's soft device doesn't support security mode 2. It seems the dbus gatt api supports signed writes, by reading the documentation and code. Simply set "type" to "command" when executing a WriteValue. Signed authenticated writes will be used if the characteristic supports it and the link is unencrypted, otherwise normal Write Without Responses will be used. For the GATT server, set the characteristic flags to include "authenticated-signed-writes". I'm not sure how to make the bonding and connection setup to actually use security mode 2 instead of mode 1 though. Security mode 3 doesn't exist for BLE. It exists for Bluetooth classic though, so maybe that's what they're referring to. /Emil
