As I know, in BLE Secure-Connections Only (SCO) mode, all incoming and outgoing traffic between two paired devices is both authenticated and encrypted. However, BLE also allows to assign individual access permissions to attributes.

Thus, I am wondering whether the BLE specification allows the existence of attributes that neither require authentication nor encryption if two devices are communicating in SCO mode. To give a concrete example: Can device A have an attribute that does not require security and can device B access that attribute without security?

CodePudding user response：

Note that the Secure Connections Only mode is just a high-level "concept" in GAP that doesn't really exist on the ATT/GATT protocol level.

This is all in the spec there is to say about it (Bluetooth Core specification v5.3, Vol 3 Part C (GAP)):

10.2.4 Secure Connections Only mode

A device may be in a Secure Connections Only mode. When in Secure Connections Only mode only security mode 1 level 4 shall be used except for services that only require security mode 1 level 1.

The device shall only accept new outgoing and incoming service level connections for services that require Security Mode 1, Level 4 when the remote device supports LE Secure Connections and authenticated pairing is used.

Mode 1 level 1 means unencrypted, unauthenticated. Mode 1 level 4 means that LE Secure Connections are used with authenticated pairing, i.e. not "LESC Just Works".

So to claim that your device is in SCO mode, you can have a mix of services that don't require any encryption at all and services that only allow to be used when authenticated LESC is used. The services that don't require any encryption can be used at anytime, both when the link is encrypted and when it is unencrypted. The other services can only be used when the connection is encrypted with authenticated LESC.

If I interpret it correctly, you can therefore not have a GATT service with multiple characteristics such that one characteristic is accessable without encryption and one other characteristic is only accessable with encryption. In that case you need to split it up into two services, one without encryption requirements and one with authenticated LESC as requirement.

Anyway, "SCO mode" is just abstract terminology that doesn't have any implications in practice except that it categorises service structures. Basically what you can do with it is to print a label on your product "certified to support SCO mode". It can also be useful as a flag in Bluetooth stacks you can set that validates that the local GATT db fulfills the requirements for SCO.