summaryrefslogtreecommitdiff
path: root/net/bluetooth/smp.c
AgeCommit message (Collapse)AuthorFilesLines
2017-06-10Bluetooth: use constant time memory comparison for secret valuesJason A. Donenfeld1-19/+20
This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
2017-04-30Bluetooth: Add selftest for ECDH key generationMarcel Holtmann1-0/+38
Since the ECDH key generation takes a different path, it needs to be tested as well. For this generate the public debug key from the private debug key and compare both. This also moves the seeding of the private key into the SMP calling code to allow for easier re-use of the ECDH key generation helper. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-04-25Bluetooth: convert smp and selftest to crypto kpp APISalvatore Benedetto1-4/+4
* Convert both smp and selftest to crypto kpp API * Remove module ecc as no more required * Add ecdh_helper functions for wrapping kpp async calls This patch has been tested *only* with selftest, which is called on module loading. Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-12-08Bluetooth: SMP: Add support for H7 crypto function and CT2 auth flagJohan Hedberg1-17/+68
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>
2016-09-19Bluetooth: Fix not registering BR/EDR SMP channel with force_bredr flagSzymon Janc1-1/+4
If force_bredr is set SMP BR/EDR channel should also be for non-SC capable controllers. Since hcidev flag is persistent wrt power toggle it can be already set when calling smp_register(). This resulted in SMP BR/EDR channel not being registered even if HCI_FORCE_BREDR_SMP flag was set. This also fix NULL pointer dereference when trying to disable force_bredr after power cycle. BUG: unable to handle kernel NULL pointer dereference at 0000000000000388 IP: [<ffffffffc0493ad8>] smp_del_chan+0x18/0x80 [bluetooth] Call Trace: [<ffffffffc04950ca>] force_bredr_smp_write+0xba/0x100 [bluetooth] [<ffffffff8133be14>] full_proxy_write+0x54/0x90 [<ffffffff81245967>] __vfs_write+0x37/0x160 [<ffffffff813617f7>] ? selinux_file_permission+0xd7/0x110 [<ffffffff81356fbd>] ? security_file_permission+0x3d/0xc0 [<ffffffff810eb5b2>] ? percpu_down_read+0x12/0x50 [<ffffffff812462a5>] vfs_write+0xb5/0x1a0 [<ffffffff812476f5>] SyS_write+0x55/0xc0 [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4 Code: 48 8b 45 f0 eb c1 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 05 c6 3b 02 00 04 55 48 89 e5 41 54 53 49 89 fc 75 4b <49> 8b 9c 24 88 03 00 00 48 85 db 74 31 49 c7 84 24 88 03 00 00 RIP [<ffffffffc0493ad8>] smp_del_chan+0x18/0x80 [bluetooth] RSP <ffff8802aee3bd90> CR2: 0000000000000388 Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-07-08Bluetooth: Switch SMP to crypto_cipher_encrypt_one()Andy Lutomirski1-39/+28
SMP does ECB crypto on stack buffers. This is complicated and fragile, and it will not work if the stack is virtually allocated. Switch to the crypto_cipher interface, which is simpler and safer. Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-03-17Merge branch 'linus' of ↵Linus Torvalds1-72/+63
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto update from Herbert Xu: "Here is the crypto update for 4.6: API: - Convert remaining crypto_hash users to shash or ahash, also convert blkcipher/ablkcipher users to skcipher. - Remove crypto_hash interface. - Remove crypto_pcomp interface. - Add crypto engine for async cipher drivers. - Add akcipher documentation. - Add skcipher documentation. Algorithms: - Rename crypto/crc32 to avoid name clash with lib/crc32. - Fix bug in keywrap where we zero the wrong pointer. Drivers: - Support T5/M5, T7/M7 SPARC CPUs in n2 hwrng driver. - Add PIC32 hwrng driver. - Support BCM6368 in bcm63xx hwrng driver. - Pack structs for 32-bit compat users in qat. - Use crypto engine in omap-aes. - Add support for sama5d2x SoCs in atmel-sha. - Make atmel-sha available again. - Make sahara hashing available again. - Make ccp hashing available again. - Make sha1-mb available again. - Add support for multiple devices in ccp. - Improve DMA performance in caam. - Add hashing support to rockchip" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits) crypto: qat - remove redundant arbiter configuration crypto: ux500 - fix checks of error code returned by devm_ioremap_resource() crypto: atmel - fix checks of error code returned by devm_ioremap_resource() crypto: qat - Change the definition of icp_qat_uof_regtype hwrng: exynos - use __maybe_unused to hide pm functions crypto: ccp - Add abstraction for device-specific calls crypto: ccp - CCP versioning support crypto: ccp - Support for multiple CCPs crypto: ccp - Remove check for x86 family and model crypto: ccp - memset request context to zero during import lib/mpi: use "static inline" instead of "extern inline" lib/mpi: avoid assembler warning hwrng: bcm63xx - fix non device tree compatibility crypto: testmgr - allow rfc3686 aes-ctr variants in fips mode. crypto: qat - The AE id should be less than the maximal AE number lib/mpi: Endianness fix crypto: rockchip - add hash support for crypto engine in rk3288 crypto: xts - fix compile errors crypto: doc - add skcipher API documentation crypto: doc - update AEAD AD handling ...
2016-01-29Bluetooth: Fix incorrect removing of IRKsJohan Hedberg1-16/+0
The commit cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to fix handling of devices first using public addresses and then switching to RPAs after pairing. Unfortunately it missed a couple of key places in the code. 1. When evaluating which devices should be removed from the existing white list we also need to consider whether we have an IRK for them or not, i.e. a call to hci_find_irk_by_addr() is needed. 2. In smp_notify_keys() we should not be requiring the knowledge of the RPA, but should simply keep the IRK around if the other conditions require it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.4+
2016-01-27Bluetooth: Use skcipher and hashHerbert Xu1-72/+63
This patch replaces uses of blkcipher with skcipher and the long obsolete hash interface with shash. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Marcel Holtmann <marcel@holtmann.org>
2015-11-11Bluetooth: Fix l2cap_chan leak in SMPJohan Hedberg1-1/+6
The L2CAP core expects channel implementations to manage the reference returned by the new_connection callback. With sockets this is already handled with each channel being tied to the corresponding socket. With SMP however there's no context to tie the pointer to in the smp_new_conn_cb function. The function can also not just drop the reference since it's the only one at that point. For fixed channels (like SMP) the code path inside the L2CAP core from new_connection() to ready() is short and straight-forwards. The crucial difference is that in ready() the implementation has access to the l2cap_conn that SMP needs associate its l2cap_chan. Instead of taking a new reference in smp_ready_cb() we can simply assume to already own the reference created in smp_new_conn_cb(), i.e. there is no need to call l2cap_chan_hold(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.19+
2015-10-22Bluetooth: Fix crash in SMP when unpairingJohan Hedberg1-0/+26
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-10-21Bluetooth: Remove redundant (and possibly wrong) flag clearingJohan Hedberg1-1/+0
There's no need to clear the HCI_CONN_ENCRYPT_PEND flag in smp_failure. In fact, this may cause the encryption tracking to get out of sync as this has nothing to do with HCI activity. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-10-21Bluetooth: Don't use remote address type to decide IRK persistencyJohan Hedberg1-16/+17
There are LE devices on the market that start off by announcing their public address and then once paired switch to using private address. To be interoperable with such devices we should simply trust the fact that we're receiving an IRK from them to indicate that they may use private addresses in the future. Instead, simply tie the persistency to the bonding/no-bonding information the same way as for LTKs and CSRKs. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-09-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-6/+6
Conflicts: net/ipv4/arp.c The net/ipv4/arp.c conflict was one commit adding a new local variable while another commit was deleting one. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-17Bluetooth: Fix typo in smp_ah comment for hash functionMarcel Holtmann1-1/+1
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-09-17Bluetooth: Delay check for conn->smp in smp_conn_security()Johan Hedberg1-6/+6
There are several actions that smp_conn_security() might make that do not require a valid SMP context (conn->smp pointer). One of these actions is to encrypt the link with an existing LTK. If the SMP context wasn't initialized properly we should still allow the independent actions to be done, i.e. the check for the context should only be done at the last possible moment. Reported-by: Chuck Ebbert <cebbert.lkml@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.0+
2015-07-23Bluetooth: Fix NULL pointer dereference in smp_conn_securityJohan Hedberg1-0/+4
The l2cap_conn->smp pointer may be NULL for various valid reasons where SMP has failed to initialize properly. One such scenario is when crypto support is missing, another when the adapter has been powered on through a legacy method. The smp_conn_security() function should have the appropriate check for this situation to avoid NULL pointer dereferences. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.0+
2015-06-12Bluetooth: Use actual encryption key size for SMP over BR/EDRJohan Hedberg1-2/+2
When pairing over SMP over BR/EDR the generated LTK has by default the same key size as the BR/EDR Link Key. Make sure we don't set our Pairing Request/Response max value to anything higher than that. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-12Bluetooth: Add debugfs support for min LE encryption key sizeJohan Hedberg1-1/+50
This patch adds a debugfs control to set a different minimum LE encryption key size. This is useful for testing that implementation of the encryption key size handling is behaving correctly (e.g. that we get appropriate 'Encryption Key Size' error responses when necessary). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-12Bluetooth: Add debugfs support for max LE encryption key sizeJohan Hedberg1-4/+57
This patch adds a debugfs control to set a different maximum LE encryption key size. This is useful for testing that implementation of the encryption key size handling is behaving correctly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-10Bluetooth: Fix exposing full value of shortened LTKsJohan Hedberg1-1/+8
When we notify user space of a new LTK or distribute an LTK to the remote peer the value passed should be the shortened version so that it's easy to compare values in various traces. The core spec also sets the requirements for the shortening/masking as: "The masking shall be done after generation and before being distributed, used or stored." Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-09Bluetooth: Fix encryption key size handling for LTKsJohan Hedberg1-12/+3
The encryption key size for LTKs is supposed to be applied only at the moment of encryption. When generating a Link Key (using LE SC) from the LTK the full non-shortened value should be used. This patch modifies the code to always keep the full value around and only apply the key size when passing the value to HCI. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-05-19Bluetooth: Add debug logs for legacy SMP crypto functionsJohan Hedberg1-4/+16
To help debug legacy SMP crypto functions add debug logs of the various values involved. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-04-02Bluetooth: Export SMP selftest result in debugfsMarcel Holtmann1-9/+34
When SMP selftest is enabled, then besides printing the result into the kernel message buffer, also create a debugfs file that allows retrieving the same information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-30Bluetooth: Refactor L2CAP variables into l2cap_ctrlJohan Hedberg1-1/+1
We're getting very close to the maximum possible size of bt_skb_cb. To prepare to shrink the struct with the help of a union this patch moves all L2CAP related variables into the l2cap_ctrl struct. To later add other 'ctrl' structs the L2CAP one is renamed simple 'l2cap' instead of 'control'. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-18Bluetooth: Fix potential NULL dereference in SMP channel setupMarcel Holtmann1-3/+5
When the allocation of the L2CAP channel for the BR/EDR security manager fails, then the smp variable might be NULL. In that case do not try to free the non-existing crypto contexts Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-17Bluetooth: Add workaround for broken OS X legacy SMP pairingJohan Hedberg1-8/+67
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>
2015-03-16Bluetooth: Rename smp->local_rr into smp->local_randMarcel Holtmann1-5/+5
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Add extra SMP_DBG statement for remote OOB dataMarcel Holtmann1-0/+2
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Use smp->remote_pk + 32 instead of &smp->remote_pk[32]Marcel Holtmann1-1/+1
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Add clarifying comment when setting local OOB flagJohan Hedberg1-0/+8
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Don't send public key if OOB data verification failsJohan Hedberg1-10/+10
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Fix verifying confirm value when lacking remote OOB dataJohan Hedberg1-1/+3
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Set local OOB data flag if remote has our OOB dataJohan Hedberg1-0/+6
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Track local vs remote OOB data availabilityJohan Hedberg1-4/+6
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Fix local OOB data handling for SMPJohan Hedberg1-2/+5
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-03-16Bluetooth: Use smp->local_pk + 32 instead of &smp->local_pk[32]Marcel Holtmann1-1/+1
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Use OOB key pair for LE SC pairing with OOB methodMarcel Holtmann1-0/+20
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Add function for generating LE SC out-of-band dataMarcel Holtmann1-0/+53
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>
2015-03-16Bluetooth: Add support for AES-CMAC hash for security manager deviceMarcel Holtmann1-0/+14
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Create SMP device structure for local crypto contextMarcel Holtmann1-16/+31
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-16Bluetooth: Use kzfree instead of kfree in security managerMarcel Holtmann1-8/+8
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-13Bluetooth: Merge hdev->dbg_flags fields into hdev->dev_flagsMarcel Holtmann1-5/+5
With the extension of hdev->dev_flags utilizing a bitmap now, the space is no longer restricted. Merge the hdev->dbg_flags into hdev->dev_flags to save space on 64-bit architectures. On 32-bit architectures no size reduction happens. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-13Bluetooth: Introduce hci_dev_test_flag helper macroMarcel Holtmann1-22/+22
Instead of manually coding test_bit on hdev->dev_flags all the time, use hci_dev_test_flag helper macro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-03-12Bluetooth: Remove two else branches that are not neededMarcel Holtmann1-4/+4
The SMP code contains two else branches that are not needed since the successful test will actually leave the function. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-02-27Bluetooth: Update New CSRK event to match latest specificationJohan Hedberg1-2/+8
The 'master' parameter of the New CSRK event was recently renamed to 'type', with the old values kept for backwards compatibility as unauthenticated local/remote keys. This patch updates the code to take into account the two new (authenticated) values and ensures they get used based on the security level of the connection that the respective keys get distributed over. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-02-20Bluetooth: Use hci_copy_identity_addr() helper for SMP chan creationJohan Hedberg1-17/+7
The only reason the SMP code is essentially duplicating the hci_copy_identity_addr() function is that the helper returns the address type in the HCI format rather than the three-value format expected by l2cap_chan. This patch converts the SMP code to use the helper and then do a simple conversion from one address type to another. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-31Bluetooth: Fix OOB data present value for SMP pairingMarcel Holtmann1-1/+1
Before setting the OOB data present flag with SMP pairing, check the newly introduced present tracking that actual OOB data values have been provided. The existence of remote OOB data structure does not actually mean that the correct data values are available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-15Bluetooth: Add paranoid check for existing LE and BR/EDR SMP channelsMarcel Holtmann1-0/+12
When the SMP channels have been already registered, then print out a clear WARN_ON message that something went wrong. Also unregister the existing channels in this case before trying to register new ones. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-15Bluetooth: Don't register any SMP channel if LE is not supportedMarcel Holtmann1-0/+6
When LE features are not supported, then do not bother registering any kind of SMP channel. 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-13 13:31:54 +0000