summaryrefslogtreecommitdiff
path: root/net/bluetooth/smp.h
AgeCommit message (Collapse)AuthorFilesLines
2016-12-08Bluetooth: SMP: Add support for H7 crypto function and CT2 auth flagJohan Hedberg1-0/+1
Bluetooth 5.0 introduces a new H7 key generation function that's used when both sides of the pairing set the CT2 authentication flag to 1. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-10-22Bluetooth: Fix crash in SMP when unpairingJohan Hedberg1-0/+1
When unpairing the keys stored in hci_dev are removed. If SMP is ongoing the SMP context will also have references to these keys, so removing them from the hci_dev lists will make the pointers invalid. This can result in the following type of crashes: BUG: unable to handle kernel paging request at 6b6b6b6b IP: [<c11f26be>] __list_del_entry+0x44/0x71 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: hci_uart btqca btusb btintel btbcm btrtl hci_vhci rfcomm bluetooth_6lowpan bluetooth CPU: 0 PID: 723 Comm: kworker/u5:0 Not tainted 4.3.0-rc3+ #1379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 Workqueue: hci0 hci_rx_work [bluetooth] task: f19da940 ti: f1a94000 task.ti: f1a94000 EIP: 0060:[<c11f26be>] EFLAGS: 00010202 CPU: 0 EIP is at __list_del_entry+0x44/0x71 EAX: c0088d20 EBX: f30fcac0 ECX: 6b6b6b6b EDX: 6b6b6b6b ESI: f4b60000 EDI: c0088d20 EBP: f1a95d90 ESP: f1a95d8c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 8005003b CR2: 6b6b6b6b CR3: 319e5000 CR4: 00000690 Stack: f30fcac0 f1a95db0 f82dc3e1 f1bfc000 00000000 c106524f f1bfc000 f30fd020 f1a95dc0 f1a95dd0 f82dcbdb f1a95de0 f82dcbdb 00000067 f1bfc000 f30fd020 f1a95de0 f1a95df0 f82d1126 00000067 f82d1126 00000006 f30fd020 f1bfc000 Call Trace: [<f82dc3e1>] smp_chan_destroy+0x192/0x240 [bluetooth] [<c106524f>] ? trace_hardirqs_on_caller+0x14e/0x169 [<f82dcbdb>] smp_teardown_cb+0x47/0x64 [bluetooth] [<f82dcbdb>] ? smp_teardown_cb+0x47/0x64 [bluetooth] [<f82d1126>] l2cap_chan_del+0x5d/0x14d [bluetooth] [<f82d1126>] ? l2cap_chan_del+0x5d/0x14d [bluetooth] [<f82d40ef>] l2cap_conn_del+0x109/0x17b [bluetooth] [<f82d40ef>] ? l2cap_conn_del+0x109/0x17b [bluetooth] [<f82c0205>] ? hci_event_packet+0x5b1/0x2092 [bluetooth] [<f82d41aa>] l2cap_disconn_cfm+0x49/0x50 [bluetooth] [<f82d41aa>] ? l2cap_disconn_cfm+0x49/0x50 [bluetooth] [<f82c0228>] hci_event_packet+0x5d4/0x2092 [bluetooth] [<c1332c16>] ? skb_release_data+0x6a/0x95 [<f82ce5d4>] ? hci_send_to_monitor+0xe7/0xf4 [bluetooth] [<c1409708>] ? _raw_spin_unlock_irqrestore+0x44/0x57 [<f82b3bb0>] hci_rx_work+0xf1/0x28b [bluetooth] [<f82b3bb0>] ? hci_rx_work+0xf1/0x28b [bluetooth] [<c10635a0>] ? __lock_is_held+0x2e/0x44 [<c104772e>] process_one_work+0x232/0x432 [<c1071ddc>] ? rcu_read_lock_sched_held+0x50/0x5a [<c104772e>] ? process_one_work+0x232/0x432 [<c1047d48>] worker_thread+0x1b8/0x255 [<c1047b90>] ? rescuer_thread+0x23c/0x23c [<c104bb71>] kthread+0x91/0x96 [<c14096a7>] ? _raw_spin_unlock_irq+0x27/0x44 [<c1409d61>] ret_from_kernel_thread+0x21/0x30 [<c104bae0>] ? kthread_parkme+0x1e/0x1e To solve the issue, introduce a new smp_cancel_pairing() API that can be used to clean up the SMP state before touching the hci_dev lists. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Add function for generating LE SC out-of-band dataMarcel Holtmann1-0/+1
This patch adds a smp_generate_oob function that allows to create local out-of-band data that can be used for pairing and also provides the confirmation and random value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-12-30Bluetooth: Add skeleton for SMP self-testsJohan Hedberg1-0/+13
This patch adds the initial skeleton and kernel config option for SMP self-tests. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-12-03Bluetooth: Fix missing const declarations in SMP functionsJohan Hedberg1-2/+3
Several SMP functions take read-only data. This patch fixes the declaration of these parameters to use the const specifier as appropriate. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-12-03Bluetooth: Set the correct security level for SC LTKsJohan Hedberg1-2/+6
When the looked-up LTK is one generated by Secure Connections pairing the security level it gives is BT_SECURITY_FIPS. This patch updates the LTK request event handler to correctly set this level. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-12-03Bluetooth: Add mgmt support for LE Secure Connections LTK typesJohan Hedberg1-0/+13
We need a dedicated LTK type for LTK resulting from a Secure Connections based SMP pairing. This patch adds a new define for it and ensures that both the New LTK event as well as the Load LTKs command supports it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-12-03Bluetooth: Add basic SMP defines for LE Secure ConnectionsJohan Hedberg1-1/+24
This patch adds basic SMP defines for commands, error codes and PDU definitions for the LE Secure Connections feature. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-11-15Bluetooth: Add key preference parameter to smp_sufficient_securityJohan Hedberg1-1/+8
So far smp_sufficient_security() has returned false if we're encrypted with an STK but do have an LTK available. However, for the sake of LE CoC servers we do want to let the incoming connection through even though we're only encrypted with the STK. This patch adds a key preference parameter to smp_sufficient_security() with two possible values (enum used instead of bool for readability). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-11Bluetooth: Add smp_ltk_sec_level() helper functionJohan Hedberg1-0/+8
There are several places that need to determine the security level that an LTK can provide. This patch adds a convenience function for this to help make the code more readable. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-08Bluetooth: Add strict checks for allowed SMP PDUsJohan Hedberg1-0/+2
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-08-14Bluetooth: Make smp_chan_destroy() private to smp.cJohan Hedberg1-2/+0
There are no external users of smp_chan_destroy() so make it private to smp.c. The patch also moves the function higher up in the c-file in order to avoid forward declarations. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-08-14Bluetooth: Use L2CAP resume callback to call smp_distribute_keysJohan Hedberg1-1/+0
There's no need to export the smp_distribute_keys() function since the resume callback is called in the same scenario. This patch makes the smp_notify_keys function private (at the same time moving it higher up in smp.c to avoid forward declarations) and adds a resume callback for SMP to call it from there instead. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-08-14Bluetooth: Convert SMP to use l2cap_chan infrastructureJohan Hedberg1-1/+0
Now that we have all the necessary pieces in place we can fully convert SMP to use the L2CAP channel infrastructure. This patch adds the necessary callbacks and removes the now unneeded conn->smp_chan pointer. One notable behavioral change in this patch comes from the following code snippet: - case L2CAP_CID_SMP: - if (smp_sig_channel(conn, skb)) - l2cap_conn_del(conn->hcon, EACCES); This piece of code was essentially forcing a disconnection if garbage SMP data was received. The l2cap_conn_del() function is private to l2cap_conn.c so we don't have access to it anymore when using the L2CAP channel callbacks. Therefore, the behavior of the new code is simply to return errors in the recv() callback (which is simply the old smp_sig_channel()), but no disconnection will occur. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-08-14Bluetooth: Make AES crypto context private to SMPJohan Hedberg1-3/+2
Now that we have per-adapter SMP data thanks to the root SMP L2CAP channel we can take advantage of it and attach the AES crypto context (only used for SMP) to it. This means that the smp_irk_matches() and smp_generate_rpa() function can be converted to internally handle the AES context. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-08-14Bluetooth: Move SMP (de)initialization to smp.cJohan Hedberg1-0/+3
As preparation for moving SMP to use l2cap_chan infrastructure we need to move the (de)initialization functions to smp.c (where they'll eventually need access to the local L2CAP channel callbacks). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-03Bluetooth: Remove HCI prefix from SMP LTK definesJohan Hedberg1-0/+7
The LTK type has really nothing to do with HCI so it makes more sense to have these in smp.h than hci.h. This patch moves the defines to smp.h and removes the HCI_ prefix in the same go. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-05-20Bluetooth: Make SMP context private to smp.cJohan Hedberg1-29/+0
There are no users of the smp_chan struct outside of smp.c so move it away from smp.h. The addition of the l2cap.h include to hci_core.c, hci_conn.c and mgmt.c is something that should have been there already previously to avoid warnings of undeclared struct l2cap_conn, but the compiler warning was apparently shadowed away by the mention of l2cap_conn in the struct smp_chan definition. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-05-08Bluetooth: Add support for SMP Invalid Parameters error codeJohan Hedberg1-0/+1
The Invalid Parameters error code is used to indicate that the command length is invalid or that a parameter is outside of the specified range. This error code wasn't clearly specified in the Bluetooth 4.0 specification but since 4.1 this has been fixed. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-24Bluetooth: Remove LTK re-encryption procedureJohan Hedberg1-6/+2
Due to several devices being unable to handle this procedure reliably (resulting in forced disconnections before pairing completes) it's better to remove it altogether. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-24Bluetooth: Add SMP flag to track which side is the initiatorJohan Hedberg1-0/+1
For remotely initiated just-works pairings we want to show the user a confirmation dialog for the pairing. However, we can only know which side was the initiator by tracking which side sends the first Security Request or Pairing Request PDU. This patch adds a new SMP flag to indicate whether our side was the initiator for the pairing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-19Bluetooth: Increase SMP re-encryption delay to 500msJohan Hedberg1-1/+1
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-09Bluetooth: Add support for handling signature resolving keysMarcel Holtmann1-0/+2
The connection signature resolving key (CSRK) is used for attribute protocol signed write procedures. This change generates a new local key during pairing and requests the peer key as well. Newly generated key and received key will be provided to userspace using the New Signature Resolving Key management event. The Master CSRK can be used for verification of remote signed write PDUs and the Slave CSRK can be used for sending signed write PDUs to the remote device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-28Bluetooth: Delay LTK encryption to let remote receive all keysJohan Hedberg1-0/+3
Some devices may refuse to re-encrypt with the LTK if they haven't received all our keys yet. This patch adds a 250ms delay before attempting re-encryption with the LTK. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-28Bluetooth: Re-encrypt link after receiving an LTKJohan Hedberg1-1/+2
It's not strictly speaking required to re-encrypt a link once we receive an LTK since the connection is already encrypted with the STK. However, re-encrypting with the LTK allows us to verify that we've received an LTK that actually works. This patch updates the SMP code to request encrypting with the LTK in case we're in master role and waits until the key refresh complete event before notifying user space of the distributed keys. A new flag is also added for the SMP context to ensure that we re-encryption only once in case of multiple calls to smp_distribute_keys. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-28Bluetooth: Use __le64 type for LE random numbersMarcel Holtmann1-1/+1
The random numbers in Bluetooth Low Energy are 64-bit numbers and should also be little endian since the HCI specification is little endian. Change the whole Low Energy pairing to use __le64 instead of a byte array. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-26Bluetooth: Remove unneeded "force" parameter from smp_distribute_keys()Johan Hedberg1-1/+1
Now that to-be-received keys are properly tracked we no-longer need the "force" parameter to smp_distribute_keys(). It was essentially acting as an indicator whether all keys have been received, but now it's just redundant together with smp->remote_key_dist. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-23Bluetooth: Add SMP function for generating RPAsJohan Hedberg1-0/+1
We need a function in smp.c to generate Resolvable Random Addresses in order to support privacy. The local RPA will need to be generated before advertising, scanning or connecting and regenerated at periodic intervals. This patch adds the necessary function for RPA generation. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-19Bluetooth: Track SMP keys in the SMP contextJohan Hedberg1-0/+3
As preparation to do mgmt notification in a single place at the end of the key distribution, store the keys that need to be notified within the SMP context. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-18Bluetooth: Wait for SMP key distribution completion when pairingJohan Hedberg1-0/+1
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-18Bluetooth: Remove SMP data specific crypto contextJohan Hedberg1-1/+0
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-18Bluetooth: Enable support for remote IRK distributionJohan Hedberg1-0/+4
This patch does the necessary changes to request the remote device to distribute its IRK to us during the SMP pairing procedure. This includes setting the right key distribution values in the pairing request/response and handling of the two related SMP PDUs, i.e. Identity Information and Identity Address Information. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-18Bluetooth: Add smp_irk_matches helper functionJohan Hedberg1-0/+3
This patch adds a helper function to check whether a given IRK matches a given Resolvable Private Address (RPA). The function will be needed for implementing the rest of address resolving support. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-18Bluetooth: Fix minor whitespace issues in SMP codeJohan Hedberg1-1/+0
This patch fixes a couple of unnecessary empty lines in the SMP code. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05Bluetooth: Add smp_sufficient_security helper functionJohan Hedberg1-0/+1
This function is needed both by the smp_conn_security function as well as upcoming code to check for the security requirements when receiving an L2CAP connect request over LE. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-11Bluetooth: Move smp.h header file into net/bluetooth/Marcel Holtmann1-0/+146
The smp.h header file is only used internally by the bluetooth.ko module and is not a public API. So make it local to the core Bluetooth module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 18:53:47 +0000