Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <edd02903-6460-76c0-7b96-169c15d42699@student.tugraz.at>
In-Reply-To: <edd02903-6460-76c0-7b96-169c15d42699@student.tugraz.at>
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Fri, 14 Aug 2020 12:49:10 +0200
Message-ID: <CAO1O6sf5WKvFZxzRnRo2UweFSJ-0Z7OkQXyfcu6nc_BTjOGq7w@mail.gmail.com>
Subject: Re: [BlueZ] BLE Security Mode 2 Support
To:     Christian Seifert <christian.seifert@student.tugraz.at>
Cc:     Bluetooth Kernel Mailing List <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Christian,

Den fre 14 aug. 2020 kl 11:21 skrev Christian Seifert
<christian.seifert@student.tugraz.at>:
>
> 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