- 17 Mar, 2015 16 commits
-
-
Johan Hedberg authored
OS X version 10.10.2 (and possibly older versions) doesn't support LE Secure Connections but incorrectly copies all authentication request bits from a Security Request to its Pairing Request. The result is that an SC capable initiator (such as BlueZ) will think OS X intends to do SC when in fact it's incapable of it: < ACL Data TX: Handle 3585 flags 0x00 dlen 6 SMP: Security Request (0x0b) len 1 Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) > ACL Data RX: Handle 3585 flags 0x02 dlen 11 SMP: Pairing Request (0x01) len 6 IO capability: KeyboardDisplay (0x04) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey IdKey Sign (0x07) < ACL Data TX: Handle 3585 flags 0x00 dlen 11 SMP: Pairing Response (0x02) len 6 IO capability: NoInputNoOutput (0x03) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey Sign (0x05) The pairing eventually fails when we get an unexpected Pairing Confirm PDU instead of a Public Key PDU: > ACL Data RX: Handle 3585 flags 0x02 dlen 21 SMP: Pairing Confirm (0x03) len 16 Confim value: bcc3bed31b8f313a78ec3cce32685faf It is only at this point that we can speculate that the remote doesn't really support SC. This patch creates a workaround for the just-works model, however the MITM case is unsolvable because the OS X user has already been requested to enter a PIN which we're now expected to randomly generate and show the user (i.e. a chicken-and-egg problem). Signed-off-by:Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The mgmt.c file should be reserved purely for HCI_CHANNEL_CONTROL. The mgmt_control() function in it is already completely generic and has a single user in hci_sock.c. This patch moves the function there and renames it a bit more appropriately to hci_mgmt_cmd() (as it's a command dispatcher). Signed-off-by:
-
Johan Hedberg authored
In order to make the mgmt command handling more generic we can't have a direct call to mgmt_init_hdev() from mgmt_control(). This patch adds a new callback to struct hci_mgmt_chan. And sets it to point to the mgmt_init_hdev() function for the HCI_CHANNEL_CONTROL instance. Signed-off-by:
-
Johan Hedberg authored
There are several mgmt protocol features that will be needed by more than just the current HCI_CHANNEL_CONTROL. These include sending generic events as well as handling pending commands. This patch moves these functions out from mgmt.c to a new mgmt_util.c file. Signed-off-by:
-
Johan Hedberg authored
To be able to have pending commands for different HCI channels we need to be able to distinguish for which channel a command was sent to. The channel information is already part of the socket data and can be fetched using the recently added hci_sock_get_channel() function. To not require all mgmt.c code to pass an extra channel parameter this patch also adds a helper pending_find() & pending_find_data() functions which act as a wrapper to the new mgmt_pending_find() & mgmt_pending_find_data() APIs. Signed-off-by:
-
Johan Hedberg authored
We'll need to have access to which HCI channel a socket is bound to, in order to manage pending mgmt commands in clean way. This patch adds a helper for the purpose. Signed-off-by:
-
Jakub Pawlowski authored
CSR controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by:
Jakub Pawlowski <jpawlowski@google.com> Signed-off-by:
-
Jakub Pawlowski authored
Intel controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by:
-
Jakub Pawlowski authored
Atheros controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by:
-
Jakub Pawlowski authored
When doing scan through mgmt api, some controllers can do both le and classic scan at same time. They can be distinguished by HCI_QUIRK_SIMULTANEOUS_DISCOVERY set. This patch enables them to use this feature when doing dual mode scan. Instead of doing le, then classic scan, both scans are run at once. Signed-off-by:
-
Jakub Pawlowski authored
This patch refactor BR/EDR inquiry and LE scan triggering logic into separate methods. Signed-off-by:
-
Jakub Pawlowski authored
Some controllers allow both LE scan and BR/EDR inquiry to run at the same time, while others allow only one, LE SCAN or BR/EDR inquiry at given time. Since this is specific to each controller, add a new quirk setting that allows drivers to tell the core wether given controller can do both LE scan and BR/EDR inquiry at same time. Signed-off-by:
-
Alexander Aring authored
This patch fix an issue when at86rf230_read_subreg was successful. The function at86rf230_read_subreg will directly call regmap_read which returns zero on successful. Nobody figured out issues yet because it was only necessary to evaluate dvdd state while probing. This could make trouble because the stack variable could have an random value. The function is also used by reset the irq line before requesting irq, but the value isn't evaluated afterwards. Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Marcel Holtmann authored
Signed-off-by:
-
Marcel Holtmann authored
When a different user requests a new set of local out-of-band data, then inform all previous users that the data has been updated. To limit the scope of users, the updates are limited to previous users. If a user has never requested out-of-band data, it will also not see the update. Signed-off-by:
-
Marcel Holtmann authored
The length of the respone packet for Read Local OOB Extended Data command has a calculation error. In case LE Secure Connections support is not enabled, the actual response is shorter. Keep this in mind and update the value accordingly. Signed-off-by:
-
- 16 Mar, 2015 21 commits
-
-
Marcel Holtmann authored
In case LE Secure Connections is not enabled, then the command for returning local out-of-band data should not include the confirmation and random value for LE SC pairing. All other fields are still valid, but these two need to be left out. In that case it is also no needed to generate the public/private key pair for out-of-band pairing. Signed-off-by:
-
Marcel Holtmann authored
This seems to be a simple typo in the debugfs entry for the remote out-of-band data entries. Signed-off-by:
-
Marcel Holtmann authored
The variable for the out-of-band random number was badly named and with that confusing. Just rename it to local_rand so it is clear what value it represents. Signed-off-by:
-
Marcel Holtmann authored
Just for pure debugging purposes print the remote out-of-band data that has been received and is going to be used. Signed-off-by:
-
Marcel Holtmann authored
Signed-off-by:
-
Johan Hedberg authored
It might be a bit counterintuitive to set a 'local' flag based on remote data. This patch adds a clarifying comment to the pairing req/rsp handlers when setting the LOCAL_OOB flag based on the PDU received from the remote side. Signed-off-by:
-
Johan Hedberg authored
When we receive the remote public key, if we have remote OOB data there's no point in sending our public key to the remote if the OOB data doesn't match. This patch moves the test for this higher up in the smp_cmd_public_key() function. Signed-off-by:
-
Johan Hedberg authored
If we haven't received remote OOB data we cannot perform any special checks on the confirm value. This patch updates the check after having received the public key to only perform the verification if we have remote OOB data present. Signed-off-by:
-
Johan Hedberg authored
If the SMP Pairing Request or Response PDU received from the remote device indicates that it has received our OOB data we should set the SMP_FLAG_LOCAL_OOB flag. Signed-off-by:
-
Johan Hedberg authored
There are several decisions in the SMP logic that depend not only on whether we're doing SMP or not, but also whether local and/or remote OOB data is present. This patch splits the existing SMP_FLAG_OOB into two new flags to track local and remote OOB data respectively. Signed-off-by:
-
Johan Hedberg authored
We need to store the local ra/rb value in order to verify the Check value received from the remote. This patch adds a new 'lr' for the local ra/rb value and makes sure it gets used when verifying the DHKey Check PDU received from the remote. Signed-off-by:
-
Marcel Holtmann authored
Signed-off-by:
-
Marcel Holtmann authored
The OOB public and secret key pair is different from the non-OOB pairing procedure. SO when OOB method is in use, then use this key pair instead of generating a new one. Signed-off-by:
-
Marcel Holtmann authored
Then the local out-of-band data for LE SC pairing is requested via Read Local OOB Extended Data command, then fill in the values generated by the smp_generate_oob function. Every call of this command will overwrite previously generated values. Signed-off-by:
-
Marcel Holtmann authored
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 authored
The security manager device will require the use of AES-CMAC hash for out-of-band data generation. This patch makes sure it is correctly set up and available. Signed-off-by:
-
Marcel Holtmann authored
The LE Secure Connections Confirmation Value and LE Secure Connections Random Value contants are required for the out-of-band data and so just define them. Signed-off-by:
-
Marcel Holtmann authored
Every Bluetooth Low Energy controller requires a local crypto context to handle the resolvable private addresses. At the moment this is just a single crypto context, but for out-of-band data generation it will require an additional. To facility this, create a struct smp_dev that will hold all the extra information. This patch is just the refactoring in preparation for future changes. Signed-off-by:
-
Marcel Holtmann authored
Within the security manager, it makes sense to use kzfree instead of kfree for all data structures. This ensures that no key material leaks by accident. Signed-off-by:
-
Marcel Holtmann authored
The HCI_CONN_REMOTE_OOB connection flag is used to indicate if the pairing initiator has provided out-of-band data. However since that value is no longer used in any decision making, just remove it. It is actually unclear what purpose the OOB data present field from the HCI IO Capability Response event serves in the first place. If either side provided out-of-band data, then that data will be used for pairing. Signed-off-by:
-
Marcel Holtmann authored
When only the pairing initiator is providing out-of-band data, then the receiver side was ignoring the data. For some reason the code was checking if the initiator has received out-of-band data and only then also provide the required inidication that the acceptor actually has the needed data available. For BR/EDR out-of-band pairing it is enough if one side has received out-of-band data. There are no extra checks needed here to make this work smoothly. The only thing that is needed is to tell the controller if data is present (and if it is P-192 or P-256 or both) and then let the controller actually figure out the rest. This means the check for outgoing connection or if the initiator has indicated data are completely pointless and are in fact actually causing harm. The check in question is this one: if (conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)) { After just taking the conditional check out and always executing the code for determining the type of out-of-band data, the pairing works flawlessly and prodcudes authenticated link keys. The patch itself looks more complicated due to the reformatting of the indentation, but it essentially just a two-line change. Signed-off-by:
-
- 15 Mar, 2015 3 commits
-
-
Marcel Holtmann authored
This adds support for the simplest possible version of Read Local OOB Extended Data management command. It includes all mandatory fields, but none of the actual pairing related ones. Signed-off-by:
-
Marcel Holtmann authored
The OOB data requires to include LE Bluetooth Device Address and LE Role and so add the type constants for these fields. Signed-off-by:
-
Marcel Holtmann authored
The eir_append_data helper function is needed for generating the extended local OOB data fields. So move it up into the right location. Signed-off-by:
-
