Hi All,
I am in the process of reimplementing my MITM patches for SMP, starting
with some MGMT changes currently being uploaded here.
One of the issues that we need to agree on is the handling of IO
Capabilities. Others (Andrei) have already mentioned the "magic
numbers" these currently exist as, but there is actually a larger issue,
which I believe can be handled in one of two ways.
While BR/EDR based SSP defines 4 IO_Capabilities (DisplayOnly,
DisplayYesNo, KeyboardOnly, and NoInputNoOutput), LE-SMP defines 5. The
first four are the same as the SSP defines, the fifth one is critical to
the support of MITM security, and is KeyboardDisplay.
This new IO capability is required for SMP MITM protection, because at
least One of the two devices needs to be able to enter 6 digit numeric
passkeys, and unless we always want to claim to be keyboards only (I
would argue NO) then KeyboadDisplay is the logical choice for most full
featured linux platforms.
Therefore I would like to gage the opinions of the group on two (or
more) options:
1. Define separate LE and BR/EDR IO_Capabilities, and store them
seperately in the hci_dev structure. This would involve some further
MGMT mods to specify BR vs LE io_caps, although the MGMT_OP_PAIR_DEVICE
already includes an io_cap field that the user space could set on an
explicit "Dedicated Bonding" initiation, it would not cover either
"General Bonding", or remotely initiated bonding of any kind. Bluez
would need to specify, and the kernel store, separate io_caps for each.
2. Internally map the KeyboardDisplay io_cap inside the kernel to
DisplayYesNo for BR/EDR purposes. This would allow higher level user
space (bluez) entities to use a single io_cap (KeyboardDisplay), and
have it automatically "fallback" to DisplayYesNo, which can be looked at
as a subset of KeyboardDisplay.
Again, this is important, because without KeyboardDisplay, we will lose
the ability to do MITM protection for many LE devices which may require
it, and I would like to know opinions before I go too far down a path
which may get shot down here.
My personal option is #2, because it involves code changes in the fewest
places.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Brian,
On Thu, Nov 10, 2011, Brian Gix wrote:
> 1. Define separate LE and BR/EDR IO_Capabilities, and store them
> seperately in the hci_dev structure. This would involve some
> further MGMT mods to specify BR vs LE io_caps, although the
> MGMT_OP_PAIR_DEVICE already includes an io_cap field that the user
> space could set on an explicit "Dedicated Bonding" initiation, it
> would not cover either "General Bonding", or remotely initiated
> bonding of any kind. Bluez would need to specify, and the kernel
> store, separate io_caps for each.
>
> 2. Internally map the KeyboardDisplay io_cap inside the kernel to
> DisplayYesNo for BR/EDR purposes. This would allow higher level
> user space (bluez) entities to use a single io_cap
> (KeyboardDisplay), and have it automatically "fallback" to
> DisplayYesNo, which can be looked at as a subset of KeyboardDisplay.
>
> Again, this is important, because without KeyboardDisplay, we will
> lose the ability to do MITM protection for many LE devices which may
> require it, and I would like to know opinions before I go too far
> down a path which may get shot down here.
>
> My personal option is #2, because it involves code changes in the
> fewest places.
Option 2 is what I had already assumed that we would do, so let's go
with that.
Johan