Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bluetooth: request BLE stack to support pre-set passkey for pairing #8350

Closed
jli157 opened this issue Jun 12, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@jli157
Copy link
Contributor

commented Jun 12, 2018

Some bluetooth devices don't have either display or keyboard, but still require security features as much as possible, like secured pairing. One possible solution to support this kind of devices is that the device can store a pre-set passkey in its flash memory during manufacturing, and have the passkey printed on its case. So, a user can pick up the passkey from its case when pairing it.

Current authentication API struct bt_conn_auth_cb doesn't support this kind of requirements. The passkey passed to the function passkey_display is actually a random number.

@jhedberg

This comment has been minimized.

Copy link
Member

commented Jun 13, 2018

There are several open questions in my mind regarding this, that would be good to get some clarification and consensus on:

  • When configured to use pre-defined passkey, should the stack reject pairing from any device which cannot peform passkey entry, e.g. due to having DisplayOnly or NoInputNoOutput IO capability (I would assume yes).
  • Is there any special consideration regarding legacy vs secure connections pairing with this? Do we want to reject legacy pairing?
  • Do we want to allow the possibility of combining this together with the pairing_confirm() callback. @carlescufi suggested that devices may need/want ability to still reject certain bdaddr or similar.
  • What is the security level of the resulting keys? Can they be considered authenticated? Doing pairing with such a pre-defined key will be less secure than a completely random one (generated for each pairing at runtime), so in that sense this lands somewhere between authenticated and unauthenticated. I'd prefer leaning on the safe side and flagging the keys as unauthenticated, but it'd be good to hear other opinions.

@sjanc @Vudentz any thoughts? It would also be good to get an opinion from @holtmann on this matter.

@carlescufi

This comment has been minimized.

Copy link
Member

commented Jun 13, 2018

When configured to use pre-defined passkey, should the stack reject pairing from any device which cannot peform passkey entry, e.g. due to having DisplayOnly or NoInputNoOutput IO capability (I would assume yes).

Unless it complicates the API a lot I would leave that to the application developer to choose.

Is there any special consideration regarding legacy vs secure connections pairing with this? Do we want to reject legacy pairing?

In my opinion, no. A passkey is a passkey regardless of legacy vs LESC.

Do we want to allow the possibility of combining this together with the pairing_confirm() callback. @carlescufi suggested that devices may need/want ability to still reject certain bdaddr or similar

I think that's orthogonal to this request. We should be able to reject pairing requests from the application in order for those to implement "non-bonding" modes, regardless of whether a predefined passkey is used or not

I'd prefer leaning on the safe side and flagging the keys as unauthenticated,

I would prefer to flag it as authenticated, because you still need physical access to the device, so that's an authentication layer IMHO. Otherwise the device might support bonds with JW and others with passkey and it won't be able to differentiate or set security levels appropriately to services and char.

@jhedberg

This comment has been minimized.

Copy link
Member

commented Jun 13, 2018

When configured to use pre-defined passkey, should the stack reject pairing from any device which cannot peform passkey entry, e.g. due to having DisplayOnly or NoInputNoOutput IO capability (I would assume yes).

Unless it complicates the API a lot I would leave that to the application developer to choose.

I'd be ok with this only if we have a good use case for it. Think about it: this feature is desired so that a device with no input or output capabilities can require better security than the just-works model. However, the whole feature could be defeated by simply having the attacking device set one of the IO capabilities that I mentioned (which, combined with our local DisplayOnly, would result in the just-works model). Why would someone use a pre-defined key if connecting devices will anyway be able to bypass it? Do we really want to open the door for developers to shoot themselves in the foot with this (not understanding the implications)?

@jhedberg

This comment has been minimized.

Copy link
Member

commented Jun 13, 2018

I think that's orthogonal to this request. We should be able to reject pairing requests from the application in order for those to implement "non-bonding" modes, regardless of whether a predefined passkey is used or not

non-bonding, at least in my mind, is a global state and not a per-bdaddr one, so there are three dimensions of orthogonality here :) That said, at the moment pairing_confirm() is actually a per-spec feature where we call it when we're acceptors and the just-works model would otherwise be used. Now we'd drift outside of the spec and also call it for authenticated pairing in case the authenticated pairing is coming from a pre-defined passkey.

@jli157

This comment has been minimized.

Copy link
Contributor Author

commented Jul 27, 2018

@jhedberg is there any progress on this request? Thank you!

@jhedberg

This comment has been minimized.

Copy link
Member

commented Jul 30, 2018

@jhedberg is there any progress on this request?

@jli157 I'm working on it

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 30, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY). When a fixed passkey is
used, it comes with several limitations regarding the types of
accepted pairings as well as what callbacks are allowed in the
bt_conn_auth_cb struct.

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 30, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY). When a fixed passkey is
used, it comes with several limitations regarding the types of
accepted pairings as well as what callbacks are allowed in the
bt_conn_auth_cb struct.

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 31, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY). When a fixed passkey is
used, it comes with several limitations regarding the types of
accepted pairings as well as what callbacks are allowed in the
bt_conn_auth_cb struct.

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 31, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY). When a fixed passkey is
used, it comes with several limitations regarding the types of
accepted pairings as well as what callbacks are allowed in the
bt_conn_auth_cb struct.

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 31, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY).

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
@jhedberg

This comment has been minimized.

Copy link
Member

commented Jul 31, 2018

@jhedberg wrote:

When configured to use pre-defined passkey, should the stack reject pairing from any device which cannot peform passkey entry, e.g. due to having DisplayOnly or NoInputNoOutput IO capability (I would assume yes).

@carlescufi wrote:

Unless it complicates the API a lot I would leave that to the application developer to choose.

@jhedberg wrote:

I'd be ok with this only if we have a good use case for it.

@sjanc convinced me that we should allow this. My original thinking was stemming from the assumption that the resulting key would be unauthenticated (I was trying to err on the side of caution). However, now that we're going with an authenticated key there's no difference to how we handle authenticated vs unauthenticated pairing, meaning it's up to the high level protocol (such as GATT) to decide what services can be accessed and what not.

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 31, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY).

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit to jhedberg/zephyr that referenced this issue Jul 31, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY).

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

jhedberg added a commit that referenced this issue Aug 1, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY).

Fixes #8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

dleach02 added a commit to dleach02/zephyr that referenced this issue Sep 10, 2018

Bluetooth: Add support for fixed passkeys
Add a new bt_passkey_set() API that can be used to set a fixed passkey
to be used for pairing. The new API also requires a new Kconfig option
to be enabled first (CONFIG_BT_FIXED_PASSKEY).

Fixes zephyrproject-rtos#8350

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.