- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear broadcom、
hello,
I'm developing a device with BCM20737S SiP module and SDK 2.2 on OS X or SDK 2.2.1 on windows, and am searching for a way to realize passkey-pairing without saving exchanged keys, because iOS / Android 's bonding frequently behaves in unexpected ways.
I tried the following code and succeeded in doing this ( = passkey pair without bonding ) , but I wonder if this causes any side effect.
I don't care that users are forced to enter passkey every time, knowing that this lessen the security to a certain extent.
```
diff --git a/my_device/my_device.c b/my_device/my_device.c
@@ -626,8 +626,8 @@ void my_create(void) {
LESMP_OOB_AUTH_DATA_NOT_PRESENT, // OOBDataFlag,
#endif
#ifdef PASSKEY_PAIRING
- LESMP_AUTH_FLAG_BONDING // AuthReq,
- | LESMP_AUTH_REQ_FLAG_MITM,
+ /*LESMP_AUTH_FLAG_BONDING // AuthReq,
+ | */LESMP_AUTH_REQ_FLAG_MITM, // only passkey is required
#else
LESMP_AUTH_FLAG_BONDING, // AuthReq,
#endif
```
Please kindly let me know any slightest info or related discussions you aware of.
Best,
Takashi
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
From what I researched from google:
"The terms pairing and encryption are basically the same within the context of BLE, but bonding is not the same as pairing. It is also important to note that both encryption and bonding are necessary in order to access authenticated GATT operations. You cannot perform authenticated operations if you only encrypt the link."
So if you have any attributes that need authentications in your GATT DB, you might not be able to access them without bonding. However, I haven't tested this myself. Maybe keep that in mind?
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
From what I researched from google:
"The terms pairing and encryption are basically the same within the context of BLE, but bonding is not the same as pairing. It is also important to note that both encryption and bonding are necessary in order to access authenticated GATT operations. You cannot perform authenticated operations if you only encrypt the link."
So if you have any attributes that need authentications in your GATT DB, you might not be able to access them without bonding. However, I haven't tested this myself. Maybe keep that in mind?
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear James,
Thanks for fast reaction and helpful info
Do "authenticated operations" include read and write on characteristics with `LEGATTDB_PERM_AUTH_*ABLE` flag such as one defined as follows? :
```
CHARACTERISTIC_UUID128_WRITABLE (HANDLE_MY_CHARACTERISTIC,
HANDLE_MY_CHARACTERISTIC_VALUE, UUID_MY_CHARACTERISTIC,
LEGATTDB_CHAR_PROP_WRITE ,
LEGATTDB_PERM_WRITE_CMD | LEGATTDB_PERM_WRITE_REQ | LEGATTDB_PERM_AUTH_WRITABLE, 1),
```
Best,
Takashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes that's exactly what I was referring to when I said authenticated operations.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you.
When I tried with the code in my first post here:
```
diff --git a/my_device/my_device.c b/my_device/my_device.c
@@ -626,8 +626,8 @@ void my_create(void) {
LESMP_OOB_AUTH_DATA_NOT_PRESENT, // OOBDataFlag,
#endif
#ifdef PASSKEY_PAIRING
- LESMP_AUTH_FLAG_BONDING // AuthReq,
- | LESMP_AUTH_REQ_FLAG_MITM,
+ /*LESMP_AUTH_FLAG_BONDING // AuthReq,
+ | */LESMP_AUTH_REQ_FLAG_MITM, // only passkey is required
#else
LESMP_AUTH_FLAG_BONDING, // AuthReq,
#endif
```
write / read operations to those authenticated characteristics seemed successful and I was satisfied to the result at that time, but now I have to check if the connection is really encrypted using a sniffer.
If the result is follows:
- The connection is successfully encrypted
- Authenticated operations are also successful
- Every time the passkey-entry is required on central side
the behavior of the device doesn't obey bluetooth's pairing definition you said, so I will treat this as a bug in the wiced-sdk, and will not use the above code in my development.
Best,
Takashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay. I'll confirm this behavior on our side and talk to the developers.
Thanks.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear James,
Sorry for bothering again, but now I retried with the same code I used last time for wiced and an iPhone6 with iOS 9.1 as a central,
then the result is:
- Authenticated operations are not successful
- Every time the passkey-entry is required on central side
so, I might have mistaken...
At that time I tested the device from iOS9.0, which seems quite buggy in bluetooth, but anyway I could not reproduce the behavior I first met.
As you said, without bonding, authenticated access is not successful, and considering that my application requires authentication I cannot disable bonding. And the wiced-sdk seems working correctly in regard to bonding and pairing. This is my conclusion here.
So, please cancel your confirmation of this topic at your side.
Best,
Takashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the update.
James