RE: [RFC] Bluetooth: Fix missing MITM protection when being responding LM

Hi Johan,

Hi Timo,

On Mon, Jan 21, 2013, mail@timomueller.eu wrote:

quoted

A MITM protected SSP associaton model can be used for pairing if both
local and remote IO capabilities are set to something other than
NoInputNoOutput.

With these IO capabilities a MITM protected SSP association model is
used if we are initiating the pairing process (initiating LM).

When responding to a pairing request - remote device is the initiating
LM - the pairing should also be proteced against MITM attacks.

Signed-off-by: Timo Mueller <redacted>
---
When we were testing the iPhone 5 we noticed that the association
model changes depending on which side initiates the pairing. For
example if we paired from the phone "Just Works" was used while if the
phone was the responding LM a "Numeric Comparison" was used instead.

We'd like to enforce MITM protection in our cars whenever possible.
That is why we want to set the MITM protection even when being the
responding LM. The patch proposes this policy as the default approach.

Expected SSP accociation model:
|-------------------------------------------|
|  Device          |  SSP assocation model  |
|===========================================|
|  KeyboardDisplay |  Numeric Comparison    |
| ------------------------------------------|
|  NoInputNoOutput |  Just Works            |
| ------------------------------------------|
|  KeyboardOnly    |  Passkey Entry         |
|-------------------------------------------|

Tested Devices:
  KeyboardDisplay:
    iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
    Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
    BlueZ 5 - Simple Agent

  NoInputNoOutput:
    BlueZ 5 - Simple Agent

  KeyboardOnly:
    Logitech Keyboard Case, BlueZ 5 - Simple Agent

I've also tested this patch with the following kernels:
  3.8-rc4
  3.4

Best regards,
	 Timo

 net/bluetooth/hci_conn.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 25bfce0..806583b 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c

@@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev,

int type, bdaddr_t *dst)

quoted

 	conn->type  = type;
 	conn->mode  = HCI_CM_ACTIVE;
 	conn->state = BT_OPEN;
-	conn->auth_type = HCI_AT_GENERAL_BONDING;
 	conn->io_capability = hdev->io_capability;
 	conn->remote_auth = 0xff;
 	conn->key_type = 0xff;

+	if (hdev->io_capability == 0x03)
+		conn->auth_type = HCI_AT_GENERAL_BONDING;
+	else
+		conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
+
 	set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
 	conn->disc_timeout = HCI_DISCONN_TIMEOUT;

The question that could equally be asked is why does iOS *not* set the
MITM flag when initiating pairing to a remote device. If it did this
issue would not exist.

Welcome in the IOP WORLD :-D

Since the over all sequence of the IO capability negotiation with iOS
devices
when we're on the acceptor side might be a bit unclear to people by just
reading your commit message and patch I'll provide here a HCI trace of it:

quoted

HCI Event: IO Capability Response (0x32) plen 9

        Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
        IO capability: DisplayYesNo (0x01)
        OOB data: Authentication data not present (0x00)
        Authentication: General Bonding - MITM not required (0x04)

quoted

HCI Event: IO Capability Request (0x31) plen 6

        Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
< HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
        Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
        IO capability: DisplayYesNo (0x01)
        OOB data: Authentication data not present (0x00)
        Authentication: General Bonding - MITM not required (0x04)

Basically the BlueZ side has so far given the remote initiator the
choice whether to do just-works or not. However, I do agree that it's
good to strive for a best-possible security in the pairing (within the
limits of the available IO capabilities) so setting the MITM flag on our
side should be fine.

The one thing that I'd still consider improving is to make the setting
of the MITM flag also dependent on the remote IO capability and not just
the local one, since we do know the remote one before we need to give
our own value when we are on the acceptor side of the pairing. Thoughts?

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html