passkey pairing without bond

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
TaSa_2191066
Level 2
Level 2
First like given

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

0 Likes
1 Solution
Anonymous
Not applicable

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

View solution in original post

0 Likes
7 Replies
Anonymous
Not applicable

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

0 Likes

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    


0 Likes
Anonymous
Not applicable

Yes that's exactly what I was referring to when I said authenticated operations.

James

0 Likes

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

0 Likes
Anonymous
Not applicable

Okay. I'll confirm this behavior on our side and talk to the developers.

Thanks.

James

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

0 Likes
Anonymous
Not applicable

Thank you for the update.

James

0 Likes