Hi Johan, >Hi Timo, > >On Mon, Jan 21, 2013, mail@xxxxxxxxxxxxxx wrote: >> 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 <timo.mueller@xxxxxxxxxxxx> >> --- >> 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) >> 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: > > > 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) > > 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@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
