Is encryption working between hello_client & hello_sensor?

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

cross mob
hachc_2137126
Level 5
Level 5
10 likes given 5 likes given First like received

Hi,

  Probably that I don't know if additional trick needed for enabling the pairing + encryption for application hello_client and hello_sensor.

  I've done to remove the the following comment on both hello_client.c and hello_sensor.c:

  p.s I'm using SDK 2.2 on 20737 evb.

// Uncomment the following line to enable OOB pairing. Change oob_tk[] below to the desired key.

#define OOB_PAIRING

  But I don't see the encryption happen neither from the log message nor from air packet from sniffer.

void hello_client_encryption_changed(HCI_EVT_HDR *evt)

{

    UINT8 status = *((UINT8 *)(evt + 1));

    ble_trace1("encryption changed: %02x\n", status);

    blecen_encryptionChanged(evt);

}

void hello_sensor_encryption_changed(HCI_EVT_HDR *evt)

{

    BLEPROFILE_DB_PDU db_pdu;

    UINT8 *bda = emconninfo_getPeerPubAddr();

    ble_trace2("hello_sample, encryption changed %08x%04x\n",

                (bda[5] << 24) + (bda[4] << 16) +

                (bda[3] << 😎 + bda[2],

                (bda[1] << 😎 + bda[0]);

0 Likes
1 Solution

Hi All,

  I sincerely apologize for my fault of having the old version of sample code of hello_client.c and hello_sensor.c for testing the OOB pairing. Using the sample code from SDK 2.1.0 is not working at all for this feature.

  Now I'm able to get correct pairing and encryption by using the sample code from SDK 2.2.0.

  Truly sorry for my mistake and any inconvenience from your attention.

View solution in original post

0 Likes
18 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

How are you generating the key?

My understanding is that when Out of Band pairing is used, the key should be generated by one device and provided to another device NOT through the Bluetooth Low Energy transport, but through some other method (for example NFC, wire,...). 

I believe that the key is 16 bytes and that there is a requirement for the key to be different every time your device is engaged in pairing. 

0 Likes

Hi,

  I supposed that key is hard coded as below:

#ifdef OOB_PAIRING

const UINT8 oob_tk[LESMP_MAX_KEY_SIZE] =  {0x41, 0x59, 0x1c, 0xd5, 0xea, 0x5a, 0x49, 0x55, 0xb6, 0x3b, 0x18, 0x7c, 0x46, 0xe, 0x13, 0x52};

#endif

....

#ifdef OOB_PAIRING

    lesmp_setSMPOOBdata((UINT8*)oob_tk,LESMP_MAX_KEY_SIZE);

    lesmp_setJustWorksNotPermitted();

    lesmp_setPasskeyEntryNotPermitted();

#endif

Is there any missing steps that I need to try for this test? i.e. where should I generate/input the key to which role?

Isn't it working if I just enable the OOB to both master and slave?

0 Likes

Hi,

Any update from this topic?

More info from sniffer:

I can only see the following messages:

S->M: Security request

M->S: Pairing request

S->M: Pairing response

But the expected messages, including Pairing Confirm, Pairing Random is not happened.

encrypt_issue_to_wiced.jpg

0 Likes

are you doing this with two tag3, one a client and the other a sensor? As pointed above by mwf_mmfae, oob will require the pairing to be executed outside the bluetooth band (that's why it is called out-of-band). One example is bt pairing via nfc taggings, where the connection is established. I'm not sure you can accomplish this with just tag3...

0 Likes

Hi,

  Yes, I'm using the tag3.

  Would you please elaborate bit more about testing OOB?

  From my understanding of the specification, the TK (temporary key) should be the 128-bit random number which I suppose that it's assigned by this call

lesmp_setSMPOOBdata((UINT8*)oob_tk,LESMP_MAX_KEY_SIZE);

  What's exactly the steps for testing the OOB on top of hello_client and hello_sensor?

* To demonstrate the app, work through the following steps.

* 1. Plug the WICED eval board into your computer

* 2. Build and download the application (to the WICED board)

* 3. Pair with a client

* 4. On the client side register for notifications

* 5. Push a button on the tag to send notifications to the client

*

* To test OOB/Passkey pairing uncomment corresponding compile flag before step 2 and

* use corresponding compile in the hello_client application.

encrypt_issue_to_wiced_2.jpg

0 Likes

We need to research this with the developers to see if someone can provide guidance on how to use our OOB pairing mechanism.

0 Likes

Hi,

  Is there any news from this topic?

0 Likes

We have initiated contact with the chip developers and they are testing the OOB pairing mechanism to confirm it works as designed.  We should here something back in the next week or so.

0 Likes

Hi mwf_mmfae,

  Is there any update from the testing progress?

0 Likes

The team reported back last night and apparently could not find anything wrong.

Essentially, the OOB pairing code included in both hello-sensor and hello_client has been tested and works fine.

The developers thought that you should also be able to figure out what to change based on the comments within the code.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi,

  I still don't get the right point for enabling the security connection.

  Can someone point me out the correct path for this test over hello_client.c and hello_sensor.c?

  Please check my debugging output as enclosed.

0 Likes

I spoke to the developers and they said that uncommenting the code discussed above is really the extent of what's needed to use the sample mentioned (there are no other steps needed).

Essentially, OOB pairing should be enabled, just works should be disabled and both devices should know the same key exchanged over different transport.

Is this your understanding of how this process should be handled, or did you assume that this mechanism managed the OOB key exchange directly as well?

boont

0 Likes

Hi,

>I spoke to the developers and they said that uncommenting the code discussed above is really the extent of what's >needed to use the sample mentioned (there are no other steps needed).

Well, I hope so, but the hello_client is always failed to start(continue) the encryption procedure. I've done the test on hello_sensor with LightBlue@iPhone, and it runs well with encryption ('just work' case) feature.

After checking the air packets, the hello_client is not proceeding to send 'pairing confirm' command after receiving 'sm_pairing_rsp' from hello_sensor.

So, how did you test this at your side, just uncomment this //#define OOB_PAIRING?

>Essentially, OOB pairing should be enabled, just works should be disabled and both devices should know the same >key exchanged over different transport.

Would you show me where to *enable* OOB? any additional change on source code of hello_client.c? or any operation that I missed? And I supposed that the OOB key has been *hard coded* in both source code of hello_client and hello_sensor as I explained before. Also the following code snippet has already show the correct setting like your said.


#ifdef OOB_PAIRING

    lesmp_setSMPOOBdata((UINT8*)oob_tk,LESMP_MAX_KEY_SIZE);

    lesmp_setJustWorksNotPermitted();

    lesmp_setPasskeyEntryNotPermitted();

#endif

#ifdef PASSKEY_PAIRING

    lesmp_setSMPassKey((UINT8*)passKey,LESMP_MAX_KEY_SIZE);

    lesmp_setJustWorksNotPermitted();

#endif

From my understanding (referring to section 2.3.5.1 of part H. of vol. 3 of Bluetooth Spec), if OOB is not working, at least the just work shall be applied if non of passkey or OOB available between 2 BTLE device.

Again, from the log of air packet, the hello_client always failed to proceeding to send 'pairing confirm' after receiving 'sm_pairing_rsp' from hello_sensor. Would you explain this for me?

>Is this your understanding of how this process should be handled, or did you assume that this mechanism managed the OOB key exchange directly as well?

Don't really understand this. Am I missing any technical knowledge in running/enabling the OOB upon hello_client and hello_sensor? Please guide me the point to get out from this puzzle.

0 Likes

I will need to discuss with the developers to make sure your understanding is inline with our intended support of OOB pairing.

0 Likes

It is up to you to support only OOB pairing or allow Just Works pairing as well.  OOB indeed will provide much higher security, so it is up to your application to figure out what it needs.  To enable OOB pairing only you need to #define OOB_PAIRING on the the top of the file in both hello_client_c. and hello_sensor.c.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi victorz,

  I just need the OOB pairing.

  And unfortunately, I can't make it work by simply uncommentting #define OOB_PAIRING.

  I appreciate that if you can provide the source code that you've tested at your side for proving the OOB pairing.

  You can check the source code that I'm testing now as files enclosed.

  It already spent a lot of time in *aligning* this question, and it's remain at the same spot, no any progress from my first post.

0 Likes

Hi All,

  I sincerely apologize for my fault of having the old version of sample code of hello_client.c and hello_sensor.c for testing the OOB pairing. Using the sample code from SDK 2.1.0 is not working at all for this feature.

  Now I'm able to get correct pairing and encryption by using the sample code from SDK 2.2.0.

  Truly sorry for my mistake and any inconvenience from your attention.

0 Likes

Thanks for the update Hardy!

nsankar boont victorz

0 Likes