bluetooth: smp: CTKD issue when cross br and ble connections and security #90574
Conversation
github-actions
bot
added
area: Bluetooth
area: Bluetooth Host
github-actions
bot
requested review from
alwa-nordic,
cvinayak,
hermabe,
jhedberg,
rugeGerritsen,
sjanc,
Thalley and
theob-pro
alwa-nordic
requested review from
lylezhu2012
and removed request for
alwa-nordic
MarkWangChinese
force-pushed
the
feature/cross_br_ble_conns_security_ctkd_issue
branch
from
c0cf761 to
5d6b8f1
Compare
subsys/bluetooth/host/smp.c
Outdated
| { | ||
| struct bt_keys *keys = data; | ||
|
|
||
| if (!bt_addr_le_is_identity(&conn->le.dst) && |
There was a problem hiding this comment.
| if (!bt_addr_le_is_identity(&conn->le.dst) && | |
| if (!bt_addr_le_is_rpa(&conn->le.dst)) { | |
| return; | |
| } | |
| if ( |
MarkWangChinese
force-pushed
the
feature/cross_br_ble_conns_security_ctkd_issue
branch
from
5d6b8f1 to
3da815d
Compare
MarkWangChinese
force-pushed
the
feature/cross_br_ble_conns_security_ctkd_issue
branch
from
3da815d to
202aaa9
Compare
| if (conn->le.keys != NULL && conn->le.keys != keys) { | ||
| bt_keys_clear(conn->le.keys); | ||
| } | ||
|
|
||
| conn->le.keys = keys; | ||
| /* always update last use RPA */ | ||
| bt_addr_copy(&keys->irk.rpa, &conn->le.dst.a); | ||
| bt_addr_le_copy(&conn->le.dst, &keys->addr); |
There was a problem hiding this comment.
There are two questions here,
Question 1, if the ACL of LE has been encrypted and the LTK is changed now, how to handle this case? key refresh? or disconnect the link?
Question 2, if the ACL of LE is not encrypted and the LTK is available now, whether the ACL needs to be encrypted?
There was a problem hiding this comment.
For Q1, I think it is initiator side's issue because the BLE connection is existed and encrypted, but initiator still trigger the CTKD. I prefer to disconnect the ble connection here. what do you think?
For Q2, I don't think stack need to enable the encryption. It is the application to determine whether to encrypt the BLE connection.
There was a problem hiding this comment.
And I think the Q1 issue exist too for the normal CTKD case. Maybe we can improve/fix it in further pr.
There was a problem hiding this comment.
Hi @lylezhu2012 Could you please help to check again?
There was a problem hiding this comment.
Maybe we can add comments here for now.
There was a problem hiding this comment.
TODO comments are added.
…rity The peer uses the RPA address. A BR connection is created firstly, a subsequent BLE connection is created secondly, the BR SMP CTKD occur thirdly (The BLE LTK is derived from BR and the BR SMP distribute peer's IRK and identity address here), but the BLE LTK is saved to key pool that is not matched with the previous BLE connection because the derived LTK is saved with identity address and BLE connection uses RPA. Fix it by: Resolve the BLE connections' RPA with the derived IRK to find the previous BLE connections and match the connections with derived LTK key. Signed-off-by: Mark Wang <[email protected]>
need to consider corner cases of ctkd as the added code comments. Signed-off-by: Mark Wang <[email protected]>
MarkWangChinese
force-pushed
the
feature/cross_br_ble_conns_security_ctkd_issue
branch
from
202aaa9 to
e18810b
Compare
|
The peer uses the RPA address.
A BR connection is created firstly, a subsequent BLE connection is created secondly, the BR SMP CTKD occur thirdly (The BLE LTK is derived from BR and the BR SMP distribute peer's IRK and identity address here), but the BLE LTK is saved to key pool that is not matched with the previous BLE connection because the derived LTK is saved with identity address and BLE connection uses RPA. Fix it by: Resolve the BLE connections' RPA with the derived IRK to find the previous BLE connections and match the connections with derived LTK key.