L2CAP/LE/CFC/BV-25-C, insufficient encryption response is not possible.

[nao244]

Hello.
L2CAP/LE/CFC/BV-25-C is FAIL and I would like to share the findings.
This test case requires the LE Credit Based Connection RSP to respond with 0x0008 (insufficient encryption).
I tried various things but I got either 0x0005 (insufficient authentication) or 0x0000 (Connection Success), so I investigated.
My conclusion is that there is no case in which the Linux kernel implementation responds with 0x0008 (insufficient encryption).

The response definition is here.
https://github.com/torvalds/linux/blob/master/include/net/bluetooth/l2cap.h#L278

#define L2CAP_CR_LE_AUTHENTICATION	0x0005
#define L2CAP_CR_LE_AUTHORIZATION	0x0006
#define L2CAP_CR_LE_BAD_KEY_SIZE	0x0007
#define L2CAP_CR_LE_ENCRYPTION		0x0008

This is where the security check is carried out to determine the LE Credit Based Connection RSP.
https://github.com/torvalds/linux/blob/master/net/bluetooth/l2cap_core.c#4870
l2cap_le_connect_req()

	if (!smp_sufficient_security(conn->hcon, pchan->sec_level,
				     SMP_ALLOW_STK)) {
		result = L2CAP_CR_LE_AUTHENTICATION;
		chan = NULL;
		goto response_unlock;
	}

Looking here, there is confirmation that it will respond with 0x0005, but there is no implementation that will respond with 0x0008.

I'm going to review my ICS settings and try to avoid the test.
I hope this helps someone.

[Vudentz]

@nao244 this might be a new think then, afaik on GATT we generate the error for missing encryption based on the security level:

https://github.com/bluez/bluez/blob/master/src/shared/gatt-server.c#L410

So that would mean that medium security would return L2CAP_CR_LE_ENCRYPTION and anything higher would return L2CAP_CR_LE_AUTHENTICATION.

[nao244]

@Vudentz Thank you!
My understanding is that GATT and LE Credit-Based Flow Control are similar but require different implementations.

ATT's Insufficient Encryption is 0x0F
Table 3.4: Error codes
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/host/attribute-protocol--att-.html

LE Credit-Based Flow Control's Insufficient Encryption is 0x0008
Table 4.16: Result values ​​for the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/host/logical-link-control-and-adaptation-protocol-specification.html

I think Although the judgment is based on the same logic, it seems that different RSPs are required for each flow.

[Vudentz]

@Vudentz Thank you! My understanding is that GATT and LE Credit-Based Flow Control are similar but require different implementations.

ATT's Insufficient Encryption is 0x0F Table 3.4: Error codes https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/host/attribute-protocol--att-.html

LE Credit-Based Flow Control's Insufficient Encryption is 0x0008 Table 4.16: Result values ​​for the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/host/logical-link-control-and-adaptation-protocol-specification.html

I think Although the judgment is based on the same logic, it seems that different RSPs are required for each flow.

Yeah, I didn't mean to say they were using the exact same PDUs, just the logic around the security level.

[Vudentz]

Something like the following:

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 042d3ac3b4a3..a5bde5db58ef 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4870,7 +4870,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
 
        if (!smp_sufficient_security(conn->hcon, pchan->sec_level,
                                     SMP_ALLOW_STK)) {
-               result = L2CAP_CR_LE_AUTHENTICATION;
+               result = pchan->sec_level == BT_SECURITY_MEDIUM ?
+                       L2CAP_CR_LE_ENCRYPTION : L2CAP_CR_LE_AUTHENTICATION;
                chan = NULL;
                goto response_unlock;
        }

[nao244]

After trying different methods of operation, this patch passed L2CAP/LE/CFC/BV-25-C with below command.
But I have not been able to determine if this is the correct operation.
For example, the part that i do to be removed PTS after disconnecting from the PTS and before connecting for the second time.

l2test -r -V le_public -P 0x00F5 -E
bluetoothctl
[bluetoothctl]> scan on
[bluetoothctl]> connect [PTS]
[PTS-L2CAP-xxxx]> pair [PTS]
[agent] Passkey: 977074
[bluetoothctl]> remove [PTS]
[bluetoothctl]> connect [PTS]

[Vudentz]

After trying different methods of operation, this patch passed L2CAP/LE/CFC/BV-25-C with below command. But I have not been able to determine if this is the correct operation. For example, the part that i do to be removed PTS after disconnecting from the PTS and before connecting for the second time.

l2test -r -V le_public -P 0x00F5 -E
bluetoothctl
[bluetoothctl]> scan on
[bluetoothctl]> connect [PTS]
[PTS-L2CAP-xxxx]> pair [PTS]
[agent] Passkey: 977074
[bluetoothctl]> remove [PTS]
[bluetoothctl]> connect [PTS]

Not following why do you need to connect twice? In fact if you are the listening part shouldn't actually be PTS that acts as the central? Or the test is for 'half-paired' scenario where one side removes the keys but the other still has it?

In the long term we really want to move the functionality of the likes of l2test to bluetoothctl and then add scripts to pass PTS test cases.

[Vudentz]

@nao244 if you are able to pass the test perhaps we should integrate the fix upstream, so let me know if you have any comments regarding this change.

[nao244]

Although the intent of this PTS test case is not entirely clear, considering the scope of impact, I believe this change is a good to make this test pass.

I looked at the L2CAP test documents I had but couldn't figure out what was correct.
The setting IXIT:TSPX_iut_role_initiator also applies to this test with respect to which side initiates the pairing.