1. 11 Apr, 2014 4 commits
    • Mikel Astiz's avatar
      Bluetooth: Request MITM Protection when initiator · b16c6604
      Mikel Astiz authored
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is requested or not (Bluetooth Core Specification v4.0
      Volume 3, part C, section 6.5.3) when replying to an
      HCI_EV_IO_CAPA_REQUEST event.
      
      The recommendation is *not* to set this flag "unless the security
      policy of an available local service requires MITM Protection"
      (regardless of the bonding type). However, the kernel doesn't
      necessarily have this information and therefore the safest choice is
      to always use MITM Protection, also for General Bonding.
      
      This patch changes the behavior for the General Bonding initiator
      role, always requesting MITM Protection even if no high security level
      is used. Depending on the remote capabilities, the protection might
      not be actually used, and we will accept this locally unless of course
      a high security level was originally required.
      
      Note that this was already done for Dedicated Bonding. No-Bonding is
      left unmodified because MITM Protection is normally not desired in
      these cases.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b16c6604
    • Timo Mueller's avatar
      Bluetooth: Use MITM Protection when IO caps allow it · 7e74170a
      Timo Mueller authored
      When responding to a remotely-initiated pairing procedure, 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, regardless of the bonding type (Dedicated or
      General).
      
      This was already done for Dedicated Bonding but this patch proposes to
      use the same policy for General Bonding as well.
      
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is used ot not (Bluetooth Core Specification v4.0 Volume 3,
      part C, section 6.5.3).
      
      Note however that the recommendation is *not* to set this flag "unless
      the security policy of an available local service requires MITM
      Protection" (for both Dedicated and General Bonding). However, as we are
      already requiring MITM for Dedicated Bonding, we will follow this
      behaviour also for General Bonding.
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      7e74170a
    • Mikel Astiz's avatar
      Bluetooth: Refactor code for outgoing dedicated bonding · 6fd6b915
      Mikel Astiz authored
      Do not always set the MITM protection requirement by default in the
      field conn->auth_type, since this will be added later in
      hci_io_capa_request_evt(), as part of the requirements specified in
      HCI_OP_IO_CAPABILITY_REPLY.
      
      This avoids a hackish exception for the auto-reject case, but doesn't
      change the behavior of the code at all.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6fd6b915
    • Mikel Astiz's avatar
      Bluetooth: Refactor hci_get_auth_req() · b7f94c88
      Mikel Astiz authored
      Refactor the code without changing its behavior by handling the
      no-bonding cases first followed by General Bonding.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b7f94c88
  2. 29 Mar, 2014 2 commits
  3. 28 Mar, 2014 4 commits
  4. 27 Mar, 2014 1 commit
  5. 26 Mar, 2014 15 commits
  6. 24 Mar, 2014 8 commits
  7. 23 Mar, 2014 1 commit
  8. 21 Mar, 2014 2 commits
  9. 20 Mar, 2014 2 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix address value for early disconnection events · 61b1a7fb
      Johan Hedberg authored
      We need to ensure that we do not send events to user space with the
      identity address if we have not yet notified user space of the IRK. The
      code was previously trying to handle this for the mgmt_pair_device
      response (which worked well enough) but this is not the only connection
      related event that might be sent to user space before pairing is
      successful: another important event is Device Disconnected.
      
      The issue can actually be solved more simply than the solution
      previously used for mgmt_pair_device. Since we do have the identity
      address tracked as part of the remote IRK struct we can just copy it
      over from there to the hci_conn struct once we've for real sent the mgmt
      event for the new IRK.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      61b1a7fb
    • Johan Hedberg's avatar
      Bluetooth: Fix passkey endianess in user_confirm and notify_passkey · 39adbffe
      Johan Hedberg authored
      The passkey_notify and user_confirm functions in mgmt.c were expecting
      different endianess for the passkey, leading to a big endian bug and
      sparse warning in recently added SMP code. This patch converts both
      functions to expect host endianess and do the conversion to little
      endian only when assigning to the mgmt event struct.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      39adbffe
  10. 19 Mar, 2014 1 commit