* [PATCH v2 2/6] Bluetooth: Don't modify sec_level if auth failed
2011-04-21 7:54 [PATCH v2 1/6] Bluetooth: Add definitions for link key types Waldemar Rymarkiewicz
@ 2011-04-21 7:54 ` Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements Waldemar Rymarkiewicz
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Waldemar Rymarkiewicz @ 2011-04-21 7:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, padovan, Waldemar Rymarkiewicz
If authentication fails the security level should stay as it was set
before the process has started. Setting BT_SECURITY_LOW can hide real
security level on a link eg. having BT_SECURITY_MEDIUM on the link,
re-authenticate with failure to get BT_SECURITY_HIGH, as a result we
get BT_SECURITY_LOW on the link while the real security is still medium.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
net/bluetooth/hci_event.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 36eb062..0ceecd7 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1443,7 +1443,6 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
conn->sec_level = conn->pending_sec_level;
} else {
mgmt_auth_failed(hdev->id, &conn->dst, ev->status);
- conn->sec_level = BT_SECURITY_LOW;
}
clear_bit(HCI_CONN_AUTH_PEND, &conn->pend);
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements
2011-04-21 7:54 [PATCH v2 1/6] Bluetooth: Add definitions for link key types Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 2/6] Bluetooth: Don't modify sec_level if auth failed Waldemar Rymarkiewicz
@ 2011-04-21 7:54 ` Waldemar Rymarkiewicz
2011-04-21 10:02 ` Waldemar.Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 4/6] Bluetooth: Ignore key unauthenticated for high security Waldemar Rymarkiewicz
` (2 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Waldemar Rymarkiewicz @ 2011-04-21 7:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, padovan, Waldemar Rymarkiewicz
Keep the link key type together with connection and use it to
map security level to link key requirements. Authenticate and/or
encrypt connection if the link is insufficiently secure.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_conn.c | 61 +++++++++++++++++++++++++++++++------
net/bluetooth/hci_event.c | 4 ++
3 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 4093133..02e7256 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -226,6 +226,7 @@ struct hci_conn {
__u16 pkt_type;
__u16 link_policy;
__u32 link_mode;
+ __u8 key_type;
__u8 auth_type;
__u8 sec_level;
__u8 pending_sec_level;
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 7a6f56b..74cd755 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -287,6 +287,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->auth_type = HCI_AT_GENERAL_BONDING;
conn->io_capability = hdev->io_capability;
conn->remote_auth = 0xff;
+ conn->key_type = 0xff;
conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
@@ -535,32 +536,72 @@ static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
return 0;
}
+/* Encrypt the the link */
+static void hci_conn_encrypt(struct hci_conn *conn)
+{
+ BT_DBG("conn %p", conn);
+
+ if (!test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) {
+ struct hci_cp_set_conn_encrypt cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.encrypt = 0x01;
+ hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT, sizeof(cp),
+ &cp);
+ }
+}
+
/* Enable security */
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);
+ /* For sdp we don't need the link key. */
if (sec_level == BT_SECURITY_SDP)
return 1;
+ /* For non 2.1 devices and low security level we don't need the link
+ key. */
if (sec_level == BT_SECURITY_LOW &&
(!conn->ssp_mode || !conn->hdev->ssp_mode))
return 1;
- if (conn->link_mode & HCI_LM_ENCRYPT)
- return hci_conn_auth(conn, sec_level, auth_type);
-
+ /* For other security levels we need the link key. */
+ if (!(conn->link_mode & HCI_LM_AUTH))
+ goto auth;
+
+ /* An authenticated combination key has sufficient security for any
+ security level. */
+ if (conn->key_type == HCI_LK_AUTH_COMBINATION)
+ goto encrypt;
+
+ /* An unauthenticated combination key has sufficient security for
+ security level 1 and 2. */
+ if (conn->key_type == HCI_LK_UNAUTH_COMBINATION &&
+ (sec_level == BT_SECURITY_MEDIUM ||
+ sec_level == BT_SECURITY_LOW))
+ goto encrypt;
+
+ /* A combination key has always sufficient security for the security
+ levels 1 or 2. High security level requires the combination key
+ is generated using maximum PIN code length (16).
+ For pre 2.1 units. */
+ if (conn->key_type == HCI_LK_COMBINATION &&
+ (sec_level != BT_SECURITY_HIGH ||
+ conn->pin_length == 16))
+ goto encrypt;
+
+auth:
if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
return 0;
- if (hci_conn_auth(conn, sec_level, auth_type)) {
- struct hci_cp_set_conn_encrypt cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.encrypt = 1;
- hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
- sizeof(cp), &cp);
- }
+ hci_conn_auth(conn, sec_level, auth_type);
+ return 0;
+
+encrypt:
+ if (conn->link_mode & HCI_LM_ENCRYPT)
+ return 1;
+ hci_conn_encrypt(conn);
return 0;
}
EXPORT_SYMBOL(hci_conn_security);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 0ceecd7..1610e5f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2079,6 +2079,10 @@ static inline void hci_link_key_notify_evt(struct hci_dev *hdev, struct sk_buff
hci_conn_hold(conn);
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
pin_len = conn->pin_length;
+
+ if (ev->key_type != HCI_LK_CHANGED_COMBINATION)
+ conn->key_type = ev->key_type;
+
hci_conn_put(conn);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* RE: [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements
2011-04-21 7:54 ` [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements Waldemar Rymarkiewicz
@ 2011-04-21 10:02 ` Waldemar.Rymarkiewicz
0 siblings, 0 replies; 13+ messages in thread
From: Waldemar.Rymarkiewicz @ 2011-04-21 10:02 UTC (permalink / raw)
To: johan.hedberg, linux-bluetooth; +Cc: padovan
Hi Johan,
> /* Enable security */
> int hci_conn_security(struct hci_conn *conn, __u8 sec_level,
>__u8 auth_type) {
Just to clarify. This change modifies hciops behaviour, but it's not visible for the user.
In case of re-auth an extra authentication request is generated, but hciops will link_key_request_replay (key already exists, no check against pin len) on link_key_request.
As a result, connection will be accepted without any user notification.
Thanks,
Waldek
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 4/6] Bluetooth: Ignore key unauthenticated for high security
2011-04-21 7:54 [PATCH v2 1/6] Bluetooth: Add definitions for link key types Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 2/6] Bluetooth: Don't modify sec_level if auth failed Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 3/6] Bluetooth: Map sec_level to link key requirements Waldemar Rymarkiewicz
@ 2011-04-21 7:54 ` Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device Waldemar Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply Waldemar Rymarkiewicz
4 siblings, 0 replies; 13+ messages in thread
From: Waldemar Rymarkiewicz @ 2011-04-21 7:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, padovan, Waldemar Rymarkiewicz
High security level for pre v2.1 devices requires combination link key
authenticated by at least 16 digit PIN code.
It's also necessary to update key_type and pin_length when the key
exists and is sufficently secured for the connection as there will be
no link key notify event in that case.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
net/bluetooth/hci_event.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 1610e5f..087953e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2043,11 +2043,23 @@ static inline void hci_link_key_request_evt(struct hci_dev *hdev, struct sk_buff
}
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
+ if (conn) {
+ if (key->type == HCI_LK_UNAUTH_COMBINATION &&
+ conn->auth_type != 0xff &&
+ (conn->auth_type & 0x01)) {
+ BT_DBG("%s ignoring unauthenticated key", hdev->name);
+ goto not_found;
+ }
- if (key->type == HCI_LK_UNAUTH_COMBINATION && conn &&
- conn->auth_type != 0xff && (conn->auth_type & 0x01)) {
- BT_DBG("%s ignoring unauthenticated key", hdev->name);
- goto not_found;
+ if (key->type == HCI_LK_COMBINATION && key->pin_len < 16 &&
+ conn->pending_sec_level == BT_SECURITY_HIGH) {
+ BT_DBG("%s ignoring key unauthenticated for high \
+ security", hdev->name);
+ goto not_found;
+ }
+
+ conn->key_type = key->type;
+ conn->pin_length = key->pin_len;
}
bacpy(&cp.bdaddr, &ev->bdaddr);
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device
2011-04-21 7:54 [PATCH v2 1/6] Bluetooth: Add definitions for link key types Waldemar Rymarkiewicz
` (2 preceding siblings ...)
2011-04-21 7:54 ` [PATCH v2 4/6] Bluetooth: Ignore key unauthenticated for high security Waldemar Rymarkiewicz
@ 2011-04-21 7:54 ` Waldemar Rymarkiewicz
2011-04-21 9:53 ` Waldemar.Rymarkiewicz
2011-04-21 7:54 ` [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply Waldemar Rymarkiewicz
4 siblings, 1 reply; 13+ messages in thread
From: Waldemar Rymarkiewicz @ 2011-04-21 7:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, padovan, Waldemar Rymarkiewicz
In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.
That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).
Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
net/bluetooth/rfcomm/core.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index c997393..75535cc 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2054,6 +2054,21 @@ static int rfcomm_run(void *unused)
return 0;
}
+static int rfcomm_accept_secure(struct hci_conn *conn, struct rfcomm_dlc *d)
+{
+ BT_DBG("");
+
+ if (d->sec_level != BT_SECURITY_HIGH)
+ return 1; /* Accept */
+
+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
+ (conn->key_type == HCI_LK_COMBINATION &&
+ conn->pin_length == 16))
+ return 1;
+
+ return 0; /* Reject */
+}
+
static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
{
struct rfcomm_session *s;
@@ -2093,7 +2108,7 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
if (!test_and_clear_bit(RFCOMM_AUTH_PENDING, &d->flags))
continue;
- if (!status)
+ if (!status && rfcomm_accept_secure(conn, d))
set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
else
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* RE: [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device
2011-04-21 7:54 ` [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device Waldemar Rymarkiewicz
@ 2011-04-21 9:53 ` Waldemar.Rymarkiewicz
0 siblings, 0 replies; 13+ messages in thread
From: Waldemar.Rymarkiewicz @ 2011-04-21 9:53 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, padovan
Hi Johan,
>+static int rfcomm_accept_secure(struct hci_conn *conn, struct
>+rfcomm_dlc *d) {
>+ BT_DBG("");
>+
>+ if (d->sec_level != BT_SECURITY_HIGH)
>+ return 1; /* Accept */
>+
>+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
>+ (conn->key_type == HCI_LK_COMBINATION &&
>+ conn->pin_length == 16))
>+ return 1;
>+
>+ return 0; /* Reject */
>+}
>+
I don't know what's your approach to changing hciops behaviour, but I can guess we should not change it.
If it so, I would add
>+static int rfcomm_accept_secure(struct hci_conn *conn, struct
>+rfcomm_dlc *d) {
>+ BT_DBG("");
>+
/* Secure link is not supported in non mgmtops */
if (!test_bit(HCI_MGMT, &hdev->flags))
return 1;
>+ if (d->sec_level != BT_SECURITY_HIGH)
>+ return 1; /* Accept */
...
This way SECURITY_HIGH for hciops will behave as it's now (pin code less then 16 digit will be accepted).
Do you agree?
/Waldek
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 7:54 [PATCH v2 1/6] Bluetooth: Add definitions for link key types Waldemar Rymarkiewicz
` (3 preceding siblings ...)
2011-04-21 7:54 ` [PATCH v2 5/6] Bluetooth: Double check sec req for pre 2.1 device Waldemar Rymarkiewicz
@ 2011-04-21 7:54 ` Waldemar Rymarkiewicz
2011-04-21 8:10 ` Johan Hedberg
` (2 more replies)
4 siblings, 3 replies; 13+ messages in thread
From: Waldemar Rymarkiewicz @ 2011-04-21 7:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, padovan, Waldemar Rymarkiewicz
If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.
If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
net/bluetooth/hci_event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 087953e..3ee0060 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
/* If remote requests no-bonding follow that lead */
if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
- return 0x00;
+ return conn->auth_type & 0x01;
return conn->auth_type;
}
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 7:54 ` [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply Waldemar Rymarkiewicz
@ 2011-04-21 8:10 ` Johan Hedberg
2011-04-21 8:24 ` Waldemar.Rymarkiewicz
2011-04-26 23:59 ` Johan Hedberg
2011-04-27 23:09 ` [PATCH] " johan.hedberg
2 siblings, 1 reply; 13+ messages in thread
From: Johan Hedberg @ 2011-04-21 8:10 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-bluetooth, padovan
Hi Waldek,
On Thu, Apr 21, 2011, Waldemar Rymarkiewicz wrote:
> If host requires MITM protection notify that to controller in
> io capabilities reply even if the remote device requires no bonding.
>
> If it is not respected, host can get an unauthenticated link key while
> it expects authenticated one.
>
> Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
> ---
> net/bluetooth/hci_event.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 087953e..3ee0060 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
>
> /* If remote requests no-bonding follow that lead */
> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
> - return 0x00;
> + return conn->auth_type & 0x01;
>
> return conn->auth_type;
> }
Your other patches seem ok to me, but have you verified this one with
the BITE tester? This logic is directly copied from how it is in user
space right now and that's something we have arrived at after multiple
iterations with the BITE tester over the last few years. So I'd be very
careful when changing it.
Johan
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 8:10 ` Johan Hedberg
@ 2011-04-21 8:24 ` Waldemar.Rymarkiewicz
2011-04-25 17:09 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 13+ messages in thread
From: Waldemar.Rymarkiewicz @ 2011-04-21 8:24 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, padovan
Hi Johan,
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct
>> hci_conn *conn)
>>
>> /* If remote requests no-bonding follow that lead */
>> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
>> - return 0x00;
>> + return conn->auth_type & 0x01;
>>
>> return conn->auth_type;
>> }
>
>Your other patches seem ok to me, but have you verified this
>one with the BITE tester? This logic is directly copied from
>how it is in user space right now and that's something we have
>arrived at after multiple iterations with the BITE tester over
>the last few years. So I'd be very careful when changing it.
>
No, I did not. I don't have an access to BITE directly, but I will see if I can verify this.
I simply did some combination of manual tests with three different dongles (2.0 and two 2.1), with sspmode on/off , with auth and encrypt on/off, with required sec_level 1,2,3 in security mode 2 and 4.
Waldek
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 8:24 ` Waldemar.Rymarkiewicz
@ 2011-04-25 17:09 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 13+ messages in thread
From: Luiz Augusto von Dentz @ 2011-04-25 17:09 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: johan.hedberg, linux-bluetooth, padovan
Hi,
On Thu, Apr 21, 2011 at 11:24 AM, <Waldemar.Rymarkiewicz@tieto.com> wrote:
> Hi Johan,
>
>>> --- a/net/bluetooth/hci_event.c
>>> +++ b/net/bluetooth/hci_event.c
>>> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct
>>> hci_conn *conn)
>>>
>>> /* If remote requests no-bonding follow that lead */
>>> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
>>> - return 0x00;
>>> + return conn->auth_type & 0x01;
>>>
>>> return conn->auth_type;
>>> }
>>
>>Your other patches seem ok to me, but have you verified this
>>one with the BITE tester? This logic is directly copied from
>>how it is in user space right now and that's something we have
>>arrived at after multiple iterations with the BITE tester over
>>the last few years. So I'd be very careful when changing it.
>>
>
> No, I did not. I don't have an access to BITE directly, but I will see if I can verify this.
>
> I simply did some combination of manual tests with three different dongles (2.0 and two 2.1), with sspmode on/off , with auth and encrypt on/off, with required sec_level 1,2,3 in security mode 2 and 4.
I remember we discussing something similar regarding LE security, iirc
this avoid failing in case there is not possible to generate an
authenticated key due to lack of io capability, but I also remember
that we do check what type of link key the kernel wants when reading
from storage and return not found when e.g authenticated key is
required but we have only unauthenticated, so perhaps this is just to
make sure we pass some specific BITE test.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 7:54 ` [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply Waldemar Rymarkiewicz
2011-04-21 8:10 ` Johan Hedberg
@ 2011-04-26 23:59 ` Johan Hedberg
2011-04-27 23:09 ` [PATCH] " johan.hedberg
2 siblings, 0 replies; 13+ messages in thread
From: Johan Hedberg @ 2011-04-26 23:59 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-bluetooth, padovan
Hi Waldek,
On Thu, Apr 21, 2011, Waldemar Rymarkiewicz wrote:
> If host requires MITM protection notify that to controller in
> io capabilities reply even if the remote device requires no bonding.
>
> If it is not respected, host can get an unauthenticated link key while
> it expects authenticated one.
>
> Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
> ---
> net/bluetooth/hci_event.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 087953e..3ee0060 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
>
> /* If remote requests no-bonding follow that lead */
> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
> - return 0x00;
> + return conn->auth_type & 0x01;
I had to change this to:
return conn->remote_auth | (conn->auth_type & 0x01);
I.e. follow remote requirement and apply the MITM bit to it if the local
requirement has it. Otherwise TP/SEC/SEM/BV-04-C doesn't want to pass
(test vector used is 1.0.39.0). It seems to require us to mirror the
remote MITM requirement. Not sure why hciops is working and I haven't
had the chance to check the logs there. I'm still continuing testing so
we'll see if there are further issues with other test cases.
Johan
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] Bluetooth: Respect local MITM req in io_cap reply
2011-04-21 7:54 ` [PATCH v2 6/6] Bluetooth: Respect local MITM req in io_cap reply Waldemar Rymarkiewicz
2011-04-21 8:10 ` Johan Hedberg
2011-04-26 23:59 ` Johan Hedberg
@ 2011-04-27 23:09 ` johan.hedberg
2 siblings, 0 replies; 13+ messages in thread
From: johan.hedberg @ 2011-04-27 23:09 UTC (permalink / raw)
To: linux-bluetooth
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.
If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/hci_event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index cba0bdb..3c90736 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct hci_conn *conn)
/* If remote requests no-bonding follow that lead */
if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01)
- return 0x00;
+ return conn->remote_auth | (conn->auth_type & 0x01);
return conn->auth_type;
}
--
1.7.4.4
^ permalink raw reply related [flat|nested] 13+ messages in thread