1. 06 May, 2014 1 commit
  2. 24 Apr, 2014 3 commits
  3. 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
  4. 29 Mar, 2014 2 commits
  5. 28 Mar, 2014 4 commits
  6. 27 Mar, 2014 1 commit
  7. 26 Mar, 2014 15 commits
  8. 24 Mar, 2014 8 commits
  9. 23 Mar, 2014 1 commit
  10. 21 Mar, 2014 1 commit