1. 03 12月, 2014 4 次提交
  2. 15 11月, 2014 1 次提交
  3. 11 9月, 2014 1 次提交
  4. 09 9月, 2014 1 次提交
    • J
      Bluetooth: Add strict checks for allowed SMP PDUs · b28b4943
      Johan Hedberg 提交于
      SMP defines quite clearly when certain PDUs are to be expected/allowed
      and when not, but doesn't have any explicit request/response definition.
      So far the code has relied on each PDU handler to behave correctly if
      receiving PDUs at an unexpected moment, however this requires many
      different checks and is prone to errors.
      
      This patch introduces a generic way to keep track of allowed PDUs and
      thereby reduces the responsibility & load on individual command
      handlers. The tracking is implemented using a simple bit-mask where each
      opcode maps to its own bit. If the bit is set the corresponding PDU is
      allow and if the bit is not set the PDU is not allowed.
      
      As a simple example, when we send the Pairing Request we'd set the bit
      for Pairing Response, and when we receive the Pairing Response we'd
      clear the bit for Pairing Response.
      
      Since the disallowed PDU rejection is now done in a single central place
      we need to be a bit careful of which action makes most sense to all
      cases. Previously some, such as Security Request, have been simply
      ignored whereas others have caused an explicit disconnect.
      
      The only PDU rejection action that keeps good interoperability and can
      be used for all the applicable use cases is to drop the data. This may
      raise some concerns of us now being more lenient for misbehaving (and
      potentially malicious) devices, but the policy of simply dropping data
      has been a successful one for many years e.g. in L2CAP (where this is
      the *only* policy for such cases - we never request disconnection in
      l2cap_core.c because of bad data). Furthermore, we cannot prevent
      connected devices from creating the SMP context (through a Security or
      Pairing Request), and once the context exists looking up the
      corresponding bit for the received opcode and deciding to reject it is
      essentially an equally lightweight operation as the kind of rejection
      that l2cap_core.c already successfully does.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b28b4943
  5. 14 8月, 2014 5 次提交
  6. 03 7月, 2014 1 次提交
  7. 20 5月, 2014 1 次提交
  8. 08 5月, 2014 1 次提交
  9. 24 3月, 2014 2 次提交
  10. 20 3月, 2014 1 次提交
    • J
      Bluetooth: Increase SMP re-encryption delay to 500ms · 5ed884d7
      Johan Hedberg 提交于
      In some cases the current 250ms delay is not enough for the remote to
      receive the keys, as can be witnessed by the following log:
      
      > ACL Data RX: Handle 64 flags 0x02 dlen 21               [hci1] 231.414217
            SMP: Signing Information (0x0a) len 16
              Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414414
            SMP: Encryption Information (0x06) len 16
              Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29
      < ACL Data TX: Handle 64 flags 0x00 dlen 15               [hci1] 231.414466
            SMP: Master Identification (0x07) len 10
              EDIV: 0xeccc
              Rand: 0x322e0ef50bd9308a
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414505
            SMP: Signing Information (0x0a) len 16
              Signature key: bbda1b2076e2325aa66fbcdd5388f745
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.483130
              Num handles: 1
              Handle: 64
              Count: 2
      < HCI Command: LE Start Encryption (0x08|0x0019) plen 28  [hci1] 231.664211
              Handle: 64
              Random number: 0x5052ad2b75fed54b
              Encrypted diversifier: 0xb7c2
              Long term key: a336ede66711b49a84bde9b41426692e
      > HCI Event: Command Status (0x0f) plen 4                 [hci1] 231.666937
            LE Start Encryption (0x08|0x0019) ncmd 1
              Status: Success (0x00)
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.712646
              Num handles: 1
              Handle: 64
              Count: 1
      > HCI Event: Disconnect Complete (0x05) plen 4            [hci1] 232.562587
              Status: Success (0x00)
              Handle: 64
              Reason: Remote User Terminated Connection (0x13)
      
      As can be seen, the last key (Signing Information) is sent at 231.414505
      but the completed packets event for it comes only at 231.712646,
      i.e. roughly 298ms later.
      
      To have a better margin of error this patch increases the delay to
      500ms.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      5ed884d7
  11. 10 3月, 2014 1 次提交
  12. 01 3月, 2014 2 次提交
  13. 28 2月, 2014 1 次提交
  14. 27 2月, 2014 1 次提交
  15. 24 2月, 2014 1 次提交
  16. 20 2月, 2014 1 次提交
  17. 19 2月, 2014 2 次提交
    • J
      Bluetooth: Wait for SMP key distribution completion when pairing · f4a407be
      Johan Hedberg 提交于
      When we initiate pairing through mgmt_pair_device the code has so far
      been waiting for a successful HCI Encrypt Change event in order to
      respond to the mgmt command. However, putting privacy into the play we
      actually want the key distribution to be complete before replying so
      that we can include the Identity Address in the mgmt response.
      
      This patch updates the various hci_conn callbacks for LE in mgmt.c to
      only respond in the case of failure, and adds a new mgmt_smp_complete
      function that the SMP code will call once key distribution has been
      completed.
      
      Since the smp_chan_destroy function that's used to indicate completion
      and clean up the SMP context can be called from various places,
      including outside of smp.c, the easiest way to track failure vs success
      is a new flag that we set once key distribution has been successfully
      completed.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f4a407be
    • J
      Bluetooth: Remove SMP data specific crypto context · 893ce8b1
      Johan Hedberg 提交于
      Now that each HCI device has its own AES crypto context we don't need
      the one stored in the SMP data any more. This patch removes the variable
      from struct smp_chan and updates the SMP code to use the per-hdev crypto
      context.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      893ce8b1
  18. 18 2月, 2014 3 次提交
  19. 05 12月, 2013 1 次提交
  20. 11 10月, 2013 1 次提交
  21. 27 8月, 2012 1 次提交
  22. 07 8月, 2012 1 次提交
  23. 09 5月, 2012 1 次提交
  24. 13 2月, 2012 1 次提交
  25. 23 12月, 2011 1 次提交
  26. 21 9月, 2011 2 次提交
  27. 09 7月, 2011 1 次提交