You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Amr Bekhit <am...@gmail.com> on 2019/04/25 20:19:37 UTC
Mynewt Nimble OOB pairing
Hello all,
I'm interested in using OOB pairing over NFC to connect my peripheral
device to a master (an Android phone in this case). The NFC Forum has a
specification (
https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/)
which dictates how two NFC-capable BLE devices can exchange key
information. As far as I can tell from the specification, for BLE, the
peripheral can send its temporary key (TK) via NFC to the central.
Presumably, both parties would then enter that key into their Bluetooth
stacks and continue the connection process from that point on using just
BLE.
Regarding this, I have the following question. Using the nimble stack, how
can we get the peripheral to
a) generate a TK and then enter that TK into the stack.
b) continue the connection from that point forwards?
I noticed that the aforementioned specification document doesn't seem to
mention BLE Secure Connections - the TK is an aspect of BLE legacy pairing.
Does anyone know if there is a version of the standard that works with BLE
Secure Connection keys? Perhaps the assumption is that NFC pairing provides
the required identify verification and MITM protection that is provided by
BLE SC and so BLE Legacy can be used with the same level of security?
Amr
Re: Mynewt Nimble OOB pairing
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Amr,
On Tue, 30 Apr 2019 at 11:00, Amr Bekhit <am...@gmail.com> wrote:
> Hi Łukasz,
>
> Thanks for looking into this.
>
> However in logs I cannot see SMP Pairing Response, but I should see it if
> > you would use NoInputNoOutput on Nimble side as you said in previous
> email.
> > Could you confirm that you used different IO capabilities for this test?
> >
>
> Yes, for this test I had switched the device to use BLE_HS_IO_DISPLAY_ONLY.
>
Actually when looking second time into your first logs I've noticed that
BLE link was disconnected due to supervision timeout:
> HCI Event: Disconnect Complete (0x05) plen 4 #416
34.901880
Status: Success (0x00)
Handle: 64
Reason: Connection Timeout (0x08)
This is why I cannot see SMP Pairing Response there.
Wondering if this is only the BLE link which just got dropped (likely that
happen), or there is something else like some assert on Mynewt side . Can
you possibly reproduce it and show us console logs (LOG_LEVEL=0)?
>
> Once thing I did notice that was interesting - if in the NFC message, I
> don't specify the TK value and just include the device address and role,
> after touching the two devices together, Android once again asks permission
> to pair, but then brings up a dialog asking for the passkey because the
> device is configured as Display only. However, when the TK value is sent
> via NFC (as it was during the first log I sent to you), Android doesnt'
> request a passkey from the user and simply attempts to pair automatically
> and fails.
>
>
I believe that if link would not be dropped in your first test, you would
end up with same behavior.
BTW. I'm attaching here those two btsnoops you sent me for others.
I've sent you another log of the pairing process when the device does
> *not* send
> the TK value via NFC. What is the difference between the two?
>
> Amr
>
Re: Mynewt Nimble OOB pairing
Posted by Amr Bekhit <am...@gmail.com>.
Hi Łukasz,
Thanks for looking into this.
However in logs I cannot see SMP Pairing Response, but I should see it if
> you would use NoInputNoOutput on Nimble side as you said in previous email.
> Could you confirm that you used different IO capabilities for this test?
>
Yes, for this test I had switched the device to use BLE_HS_IO_DISPLAY_ONLY.
Once thing I did notice that was interesting - if in the NFC message, I
don't specify the TK value and just include the device address and role,
after touching the two devices together, Android once again asks permission
to pair, but then brings up a dialog asking for the passkey because the
device is configured as Display only. However, when the TK value is sent
via NFC (as it was during the first log I sent to you), Android doesnt'
request a passkey from the user and simply attempts to pair automatically
and fails.
I've sent you another log of the pairing process when the device does
*not* send
the TK value via NFC. What is the difference between the two?
Amr
Re: Mynewt Nimble OOB pairing
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Amr,
yes this is the Android side issue. Actually when you look at btsnoop you
can see Pairing Request showing OOB flag is 0.
SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, Legacy, No Keypresses
(0x05)
Max encryption key size: 16
Initiator key distribution: EncKey IdKey Sign (0x07)
Responder key distribution: EncKey IdKey Sign (0x07)
So having legacy paring you will not end up with using OOB as you also
concluded in your email.
However in logs I cannot see SMP Pairing Response, but I should see it if
you would use NoInputNoOutput on Nimble side as you said in previous email.
Could you confirm that you used different IO capabilities for this test?
Best
Łukasz
On Mon, 29 Apr 2019 at 20:20, Amr Bekhit <am...@gmail.com> wrote:
> After some further research and debugging, I believe I've been chasing a
> red herring.
>
> Debugging the mynewt device during the pairing process shows that the
> requester (Android phone) does not have its OOB bit set (this can be seen
> in ble_sm_lgcy_io_action). This explains why OOB was failing. It turns out
> the pairing over NFC OOB was only added the Android in version 7 Nougat
> (see
>
> https://devzone.nordicsemi.com/b/blog/posts/nrf52832-and-android-nougat-simple-and-secure-touc
> and https://devzone.nordicsemi.com/b/blog/posts/the-art-of-pairing). The
> Android device I'm using to test runs Android 6.
>
> So this explains why things aren't working as expected.
>
> On Mon, 29 Apr 2019 at 19:38, Amr Bekhit <am...@gmail.com> wrote:
>
> > Hi Łukasz,
> >
> > I've sent you the Android Bluetooth HCI log separately to your email.
> >
> > The log was saved while the following events took place:
> >
> > - With my device in idle mode, I used my phone to read the device's
> > NFC tag. I configured the NFC tag to represent a Bluetooth Carrier
> > Configuration Record, and included in it is the device address, role
> and my
> > hard-coded TK value. You can see the contents of the NFC tag as read
> by
> > Android below
> >
> > ▪▪ FORMAT ▪▪
> > Media (0x02)
> > Defined by RFC 2046
> >
> > ▪▪ TYPE ▪▪
> > application/vnd.bluetooth.le.oob
> >
> > ▪▪ PAYLOAD (30 bytes) ▪▪
> > 0x08 0x1B 0xAD 0x02 0x4B 0x8E 0x1B 0xFB 0x00 0x02 0x1C 0x00 0x11 0x10
> 0x01
> > 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F
> 0x10
> >
> >
> > - When the NFC tag is read, the device starts advertising.
> > - The Android device responds to the tag by bringing up a pop up
> > dialog asking if I would like to pair with the device. When I tap on
> yes,
> > the Android device attempts to pair.
> > - At this point, BLE_GAP_EVENT_PASSKEY_ACTION is called in the device.
> > However, the contents of event->passkey.params.action is
> BLE_SM_IOACT_DISP
> > and not BLE_SM_IOACT_OOB.
> > - The pairing fails.
> >
> > For your information, the Android device I'm using only goes up to BLE
> > 4.1, so I believe it only supports Legacy Pairing. If that is the case,
> > then according to
> >
> https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/
> ,
> > both requester and responder need to have their OOB flags set. I have a
> > feeling that the Android phone doesn't and as such, the device is falling
> > back to passkey pairing.
> >
> > Would you able to confirm this?
> >
> > On Sat, 27 Apr 2019 at 01:04, Łukasz Rymanowski <
> > lukasz.rymanowski@codecoup.pl> wrote:
> >
> >> Hi Amr,
> >>
> >> please ignore my last email, as it will not work.
> >>
> >> You should actually get BLE_GAP_EVENT_PASSKEY_ACTION with
> >> action=BLE_SM_IOACT_OOB, so there must be some bug I guess.
> >> You said you are doing your test with Android - could you send btsnoop
> >> from
> >> your Android device or take btmon logs from Mynewt side (
> >> https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
> >>
> >> Best
> >> Łukasz
> >>
> >> On Fri, 26 Apr 2019 at 23:04, Łukasz Rymanowski <
> >> lukasz.rymanowski@codecoup.pl> wrote:
> >>
> >> > Hi Amr,
> >> >
> >> > I would call it on gap connected event. Then OOB data are stored and
> SM
> >> > can present/use OOB flag during pairing.
> >> >
> >> > Best
> >> > Lukasz
> >> >
> >> > On Fri, Apr 26, 2019, 18:57 Amr Bekhit <am...@gmail.com> wrote:
> >> >
> >> >> Hi Łukasz,
> >> >>
> >> >> Thanks for your reply. Where and when should the call to
> >> ble_sm_inject_io
> >> >> take place? In my current setup, I had configured my device to use
> >> passkey
> >> >> pairing, but for testing purposes, was hardcoding the passkey. The
> BLE
> >> >> stack was requesting the passkey by calling the GAP event callback
> with
> >> >> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the
> >> passkey
> >> >> as follows:
> >> >>
> >> >> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> >> >> pk.action = event->passkey.params.action;
> >> >> pk.passkey = 123456;
> >> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> >> >> dprintf("ble_sm_inject_io result: %d\n", rc);
> >> >> }
> >> >>
> >> >> In order to support OOB, I've changed my BLE syscfg configuration to
> >> the
> >> >> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
> >> >>
> >> >> BLE_ROLE_CENTRAL: 0
> >> >> BLE_ROLE_OBSERVER: 0
> >> >>
> >> >> BLE_SM_LEGACY: 1
> >> >> BLE_SM_SC: 1
> >> >> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
> >> >> BLE_SM_OOB_DATA_FLAG: 1
> >> >> BLE_SM_MITM: 1
> >> >> BLE_SM_BONDING: 1
> >> >> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC |
> >> BLE_SM_PAIR_KEY_DIST_ID |
> >> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> >> >> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC |
> >> BLE_SM_PAIR_KEY_DIST_ID
> >> >> |
> >> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> >> >> BLE_STORE_CONFIG_PERSIST: 1
> >> >>
> >> >> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with
> the
> >> >> following code to load in a hard-coded TK:
> >> >>
> >> >> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
> >> >> pk.action = event->passkey.params.action;
> >> >> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
> >> >> memcpy(pk.oob, tk, sizeof(tk));
> >> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> >> >> dprintf("ble_sm_inject_io result: %d\n", rc);
> >> >> }
> >> >>
> >> >> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not
> being
> >> >> called anymore.
> >> >>
> >> >> So the question is, at what point and where would I call
> >> ble_sm_inject_io
> >> >> to insert the TK value?
> >> >>
> >> >> Amr
> >> >>
> >> >>
> >> >> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
> >> >> lukasz.rymanowski@codecoup.pl> wrote:
> >> >>
> >> >> > Hi Amr,
> >> >> >
> >> >> > Nimble does support OOB for Legacy and Secure Connections Pairing.
> >> >> > In both cases you just need to provide OOB (TK) data exchanged by
> >> other
> >> >> > means e.g. NFC to the NimBLE stack using "int
> >> ble_sm_inject_io(uint16_t
> >> >> > conn_handle, struct ble_sm_io *pkey)".
> >> >> >
> >> >> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
> >> >> >
> >> >> > Hope that helps
> >> >> >
> >> >> > Best
> >> >> > Łukasz
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com>
> >> wrote:
> >> >> >
> >> >> > > Hello all,
> >> >> > >
> >> >> > > I'm interested in using OOB pairing over NFC to connect my
> >> peripheral
> >> >> > > device to a master (an Android phone in this case). The NFC Forum
> >> has
> >> >> a
> >> >> > > specification (
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> >> >> > > )
> >> >> > > which dictates how two NFC-capable BLE devices can exchange key
> >> >> > > information. As far as I can tell from the specification, for
> BLE,
> >> the
> >> >> > > peripheral can send its temporary key (TK) via NFC to the
> central.
> >> >> > > Presumably, both parties would then enter that key into their
> >> >> Bluetooth
> >> >> > > stacks and continue the connection process from that point on
> using
> >> >> just
> >> >> > > BLE.
> >> >> > >
> >> >> > > Regarding this, I have the following question. Using the nimble
> >> stack,
> >> >> > how
> >> >> > > can we get the peripheral to
> >> >> > > a) generate a TK and then enter that TK into the stack.
> >> >> > > b) continue the connection from that point forwards?
> >> >> > >
> >> >> > > I noticed that the aforementioned specification document doesn't
> >> seem
> >> >> to
> >> >> > > mention BLE Secure Connections - the TK is an aspect of BLE
> legacy
> >> >> > pairing.
> >> >> > > Does anyone know if there is a version of the standard that works
> >> with
> >> >> > BLE
> >> >> > > Secure Connection keys? Perhaps the assumption is that NFC
> pairing
> >> >> > provides
> >> >> > > the required identify verification and MITM protection that is
> >> >> provided
> >> >> > by
> >> >> > > BLE SC and so BLE Legacy can be used with the same level of
> >> security?
> >> >> > >
> >> >> > > Amr
> >> >> > >
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: Mynewt Nimble OOB pairing
Posted by Amr Bekhit <am...@gmail.com>.
After some further research and debugging, I believe I've been chasing a
red herring.
Debugging the mynewt device during the pairing process shows that the
requester (Android phone) does not have its OOB bit set (this can be seen
in ble_sm_lgcy_io_action). This explains why OOB was failing. It turns out
the pairing over NFC OOB was only added the Android in version 7 Nougat
(see
https://devzone.nordicsemi.com/b/blog/posts/nrf52832-and-android-nougat-simple-and-secure-touc
and https://devzone.nordicsemi.com/b/blog/posts/the-art-of-pairing). The
Android device I'm using to test runs Android 6.
So this explains why things aren't working as expected.
On Mon, 29 Apr 2019 at 19:38, Amr Bekhit <am...@gmail.com> wrote:
> Hi Łukasz,
>
> I've sent you the Android Bluetooth HCI log separately to your email.
>
> The log was saved while the following events took place:
>
> - With my device in idle mode, I used my phone to read the device's
> NFC tag. I configured the NFC tag to represent a Bluetooth Carrier
> Configuration Record, and included in it is the device address, role and my
> hard-coded TK value. You can see the contents of the NFC tag as read by
> Android below
>
> ▪▪ FORMAT ▪▪
> Media (0x02)
> Defined by RFC 2046
>
> ▪▪ TYPE ▪▪
> application/vnd.bluetooth.le.oob
>
> ▪▪ PAYLOAD (30 bytes) ▪▪
> 0x08 0x1B 0xAD 0x02 0x4B 0x8E 0x1B 0xFB 0x00 0x02 0x1C 0x00 0x11 0x10 0x01
> 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10
>
>
> - When the NFC tag is read, the device starts advertising.
> - The Android device responds to the tag by bringing up a pop up
> dialog asking if I would like to pair with the device. When I tap on yes,
> the Android device attempts to pair.
> - At this point, BLE_GAP_EVENT_PASSKEY_ACTION is called in the device.
> However, the contents of event->passkey.params.action is BLE_SM_IOACT_DISP
> and not BLE_SM_IOACT_OOB.
> - The pairing fails.
>
> For your information, the Android device I'm using only goes up to BLE
> 4.1, so I believe it only supports Legacy Pairing. If that is the case,
> then according to
> https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/,
> both requester and responder need to have their OOB flags set. I have a
> feeling that the Android phone doesn't and as such, the device is falling
> back to passkey pairing.
>
> Would you able to confirm this?
>
> On Sat, 27 Apr 2019 at 01:04, Łukasz Rymanowski <
> lukasz.rymanowski@codecoup.pl> wrote:
>
>> Hi Amr,
>>
>> please ignore my last email, as it will not work.
>>
>> You should actually get BLE_GAP_EVENT_PASSKEY_ACTION with
>> action=BLE_SM_IOACT_OOB, so there must be some bug I guess.
>> You said you are doing your test with Android - could you send btsnoop
>> from
>> your Android device or take btmon logs from Mynewt side (
>> https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
>>
>> Best
>> Łukasz
>>
>> On Fri, 26 Apr 2019 at 23:04, Łukasz Rymanowski <
>> lukasz.rymanowski@codecoup.pl> wrote:
>>
>> > Hi Amr,
>> >
>> > I would call it on gap connected event. Then OOB data are stored and SM
>> > can present/use OOB flag during pairing.
>> >
>> > Best
>> > Lukasz
>> >
>> > On Fri, Apr 26, 2019, 18:57 Amr Bekhit <am...@gmail.com> wrote:
>> >
>> >> Hi Łukasz,
>> >>
>> >> Thanks for your reply. Where and when should the call to
>> ble_sm_inject_io
>> >> take place? In my current setup, I had configured my device to use
>> passkey
>> >> pairing, but for testing purposes, was hardcoding the passkey. The BLE
>> >> stack was requesting the passkey by calling the GAP event callback with
>> >> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the
>> passkey
>> >> as follows:
>> >>
>> >> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
>> >> pk.action = event->passkey.params.action;
>> >> pk.passkey = 123456;
>> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
>> >> dprintf("ble_sm_inject_io result: %d\n", rc);
>> >> }
>> >>
>> >> In order to support OOB, I've changed my BLE syscfg configuration to
>> the
>> >> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
>> >>
>> >> BLE_ROLE_CENTRAL: 0
>> >> BLE_ROLE_OBSERVER: 0
>> >>
>> >> BLE_SM_LEGACY: 1
>> >> BLE_SM_SC: 1
>> >> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
>> >> BLE_SM_OOB_DATA_FLAG: 1
>> >> BLE_SM_MITM: 1
>> >> BLE_SM_BONDING: 1
>> >> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC |
>> BLE_SM_PAIR_KEY_DIST_ID |
>> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
>> >> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC |
>> BLE_SM_PAIR_KEY_DIST_ID
>> >> |
>> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
>> >> BLE_STORE_CONFIG_PERSIST: 1
>> >>
>> >> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
>> >> following code to load in a hard-coded TK:
>> >>
>> >> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
>> >> pk.action = event->passkey.params.action;
>> >> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
>> >> memcpy(pk.oob, tk, sizeof(tk));
>> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
>> >> dprintf("ble_sm_inject_io result: %d\n", rc);
>> >> }
>> >>
>> >> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
>> >> called anymore.
>> >>
>> >> So the question is, at what point and where would I call
>> ble_sm_inject_io
>> >> to insert the TK value?
>> >>
>> >> Amr
>> >>
>> >>
>> >> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
>> >> lukasz.rymanowski@codecoup.pl> wrote:
>> >>
>> >> > Hi Amr,
>> >> >
>> >> > Nimble does support OOB for Legacy and Secure Connections Pairing.
>> >> > In both cases you just need to provide OOB (TK) data exchanged by
>> other
>> >> > means e.g. NFC to the NimBLE stack using "int
>> ble_sm_inject_io(uint16_t
>> >> > conn_handle, struct ble_sm_io *pkey)".
>> >> >
>> >> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
>> >> >
>> >> > Hope that helps
>> >> >
>> >> > Best
>> >> > Łukasz
>> >> >
>> >> >
>> >> >
>> >> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com>
>> wrote:
>> >> >
>> >> > > Hello all,
>> >> > >
>> >> > > I'm interested in using OOB pairing over NFC to connect my
>> peripheral
>> >> > > device to a master (an Android phone in this case). The NFC Forum
>> has
>> >> a
>> >> > > specification (
>> >> > >
>> >> > >
>> >> >
>> >>
>> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
>> >> > > )
>> >> > > which dictates how two NFC-capable BLE devices can exchange key
>> >> > > information. As far as I can tell from the specification, for BLE,
>> the
>> >> > > peripheral can send its temporary key (TK) via NFC to the central.
>> >> > > Presumably, both parties would then enter that key into their
>> >> Bluetooth
>> >> > > stacks and continue the connection process from that point on using
>> >> just
>> >> > > BLE.
>> >> > >
>> >> > > Regarding this, I have the following question. Using the nimble
>> stack,
>> >> > how
>> >> > > can we get the peripheral to
>> >> > > a) generate a TK and then enter that TK into the stack.
>> >> > > b) continue the connection from that point forwards?
>> >> > >
>> >> > > I noticed that the aforementioned specification document doesn't
>> seem
>> >> to
>> >> > > mention BLE Secure Connections - the TK is an aspect of BLE legacy
>> >> > pairing.
>> >> > > Does anyone know if there is a version of the standard that works
>> with
>> >> > BLE
>> >> > > Secure Connection keys? Perhaps the assumption is that NFC pairing
>> >> > provides
>> >> > > the required identify verification and MITM protection that is
>> >> provided
>> >> > by
>> >> > > BLE SC and so BLE Legacy can be used with the same level of
>> security?
>> >> > >
>> >> > > Amr
>> >> > >
>> >> >
>> >>
>> >
>>
>
Re: Mynewt Nimble OOB pairing
Posted by Amr Bekhit <am...@gmail.com>.
Hi Łukasz,
I've sent you the Android Bluetooth HCI log separately to your email.
The log was saved while the following events took place:
- With my device in idle mode, I used my phone to read the device's NFC
tag. I configured the NFC tag to represent a Bluetooth Carrier
Configuration Record, and included in it is the device address, role and my
hard-coded TK value. You can see the contents of the NFC tag as read by
Android below
▪▪ FORMAT ▪▪
Media (0x02)
Defined by RFC 2046
▪▪ TYPE ▪▪
application/vnd.bluetooth.le.oob
▪▪ PAYLOAD (30 bytes) ▪▪
0x08 0x1B 0xAD 0x02 0x4B 0x8E 0x1B 0xFB 0x00 0x02 0x1C 0x00 0x11 0x10 0x01
0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10
- When the NFC tag is read, the device starts advertising.
- The Android device responds to the tag by bringing up a pop up dialog
asking if I would like to pair with the device. When I tap on yes, the
Android device attempts to pair.
- At this point, BLE_GAP_EVENT_PASSKEY_ACTION is called in the device.
However, the contents of event->passkey.params.action is BLE_SM_IOACT_DISP
and not BLE_SM_IOACT_OOB.
- The pairing fails.
For your information, the Android device I'm using only goes up to BLE 4.1,
so I believe it only supports Legacy Pairing. If that is the case, then
according to
https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/,
both requester and responder need to have their OOB flags set. I have a
feeling that the Android phone doesn't and as such, the device is falling
back to passkey pairing.
Would you able to confirm this?
On Sat, 27 Apr 2019 at 01:04, Łukasz Rymanowski <
lukasz.rymanowski@codecoup.pl> wrote:
> Hi Amr,
>
> please ignore my last email, as it will not work.
>
> You should actually get BLE_GAP_EVENT_PASSKEY_ACTION with
> action=BLE_SM_IOACT_OOB, so there must be some bug I guess.
> You said you are doing your test with Android - could you send btsnoop from
> your Android device or take btmon logs from Mynewt side (
> https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
>
> Best
> Łukasz
>
> On Fri, 26 Apr 2019 at 23:04, Łukasz Rymanowski <
> lukasz.rymanowski@codecoup.pl> wrote:
>
> > Hi Amr,
> >
> > I would call it on gap connected event. Then OOB data are stored and SM
> > can present/use OOB flag during pairing.
> >
> > Best
> > Lukasz
> >
> > On Fri, Apr 26, 2019, 18:57 Amr Bekhit <am...@gmail.com> wrote:
> >
> >> Hi Łukasz,
> >>
> >> Thanks for your reply. Where and when should the call to
> ble_sm_inject_io
> >> take place? In my current setup, I had configured my device to use
> passkey
> >> pairing, but for testing purposes, was hardcoding the passkey. The BLE
> >> stack was requesting the passkey by calling the GAP event callback with
> >> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the
> passkey
> >> as follows:
> >>
> >> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> >> pk.action = event->passkey.params.action;
> >> pk.passkey = 123456;
> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> >> dprintf("ble_sm_inject_io result: %d\n", rc);
> >> }
> >>
> >> In order to support OOB, I've changed my BLE syscfg configuration to the
> >> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
> >>
> >> BLE_ROLE_CENTRAL: 0
> >> BLE_ROLE_OBSERVER: 0
> >>
> >> BLE_SM_LEGACY: 1
> >> BLE_SM_SC: 1
> >> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
> >> BLE_SM_OOB_DATA_FLAG: 1
> >> BLE_SM_MITM: 1
> >> BLE_SM_BONDING: 1
> >> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID
> |
> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> >> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC |
> BLE_SM_PAIR_KEY_DIST_ID
> >> |
> >> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> >> BLE_STORE_CONFIG_PERSIST: 1
> >>
> >> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
> >> following code to load in a hard-coded TK:
> >>
> >> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
> >> pk.action = event->passkey.params.action;
> >> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
> >> memcpy(pk.oob, tk, sizeof(tk));
> >> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> >> dprintf("ble_sm_inject_io result: %d\n", rc);
> >> }
> >>
> >> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
> >> called anymore.
> >>
> >> So the question is, at what point and where would I call
> ble_sm_inject_io
> >> to insert the TK value?
> >>
> >> Amr
> >>
> >>
> >> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
> >> lukasz.rymanowski@codecoup.pl> wrote:
> >>
> >> > Hi Amr,
> >> >
> >> > Nimble does support OOB for Legacy and Secure Connections Pairing.
> >> > In both cases you just need to provide OOB (TK) data exchanged by
> other
> >> > means e.g. NFC to the NimBLE stack using "int
> ble_sm_inject_io(uint16_t
> >> > conn_handle, struct ble_sm_io *pkey)".
> >> >
> >> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
> >> >
> >> > Hope that helps
> >> >
> >> > Best
> >> > Łukasz
> >> >
> >> >
> >> >
> >> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com> wrote:
> >> >
> >> > > Hello all,
> >> > >
> >> > > I'm interested in using OOB pairing over NFC to connect my
> peripheral
> >> > > device to a master (an Android phone in this case). The NFC Forum
> has
> >> a
> >> > > specification (
> >> > >
> >> > >
> >> >
> >>
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> >> > > )
> >> > > which dictates how two NFC-capable BLE devices can exchange key
> >> > > information. As far as I can tell from the specification, for BLE,
> the
> >> > > peripheral can send its temporary key (TK) via NFC to the central.
> >> > > Presumably, both parties would then enter that key into their
> >> Bluetooth
> >> > > stacks and continue the connection process from that point on using
> >> just
> >> > > BLE.
> >> > >
> >> > > Regarding this, I have the following question. Using the nimble
> stack,
> >> > how
> >> > > can we get the peripheral to
> >> > > a) generate a TK and then enter that TK into the stack.
> >> > > b) continue the connection from that point forwards?
> >> > >
> >> > > I noticed that the aforementioned specification document doesn't
> seem
> >> to
> >> > > mention BLE Secure Connections - the TK is an aspect of BLE legacy
> >> > pairing.
> >> > > Does anyone know if there is a version of the standard that works
> with
> >> > BLE
> >> > > Secure Connection keys? Perhaps the assumption is that NFC pairing
> >> > provides
> >> > > the required identify verification and MITM protection that is
> >> provided
> >> > by
> >> > > BLE SC and so BLE Legacy can be used with the same level of
> security?
> >> > >
> >> > > Amr
> >> > >
> >> >
> >>
> >
>
Re: Mynewt Nimble OOB pairing
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Amr,
please ignore my last email, as it will not work.
You should actually get BLE_GAP_EVENT_PASSKEY_ACTION with
action=BLE_SM_IOACT_OOB, so there must be some bug I guess.
You said you are doing your test with Android - could you send btsnoop from
your Android device or take btmon logs from Mynewt side (
https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
Best
Łukasz
On Fri, 26 Apr 2019 at 23:04, Łukasz Rymanowski <
lukasz.rymanowski@codecoup.pl> wrote:
> Hi Amr,
>
> I would call it on gap connected event. Then OOB data are stored and SM
> can present/use OOB flag during pairing.
>
> Best
> Lukasz
>
> On Fri, Apr 26, 2019, 18:57 Amr Bekhit <am...@gmail.com> wrote:
>
>> Hi Łukasz,
>>
>> Thanks for your reply. Where and when should the call to ble_sm_inject_io
>> take place? In my current setup, I had configured my device to use passkey
>> pairing, but for testing purposes, was hardcoding the passkey. The BLE
>> stack was requesting the passkey by calling the GAP event callback with
>> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the passkey
>> as follows:
>>
>> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
>> pk.action = event->passkey.params.action;
>> pk.passkey = 123456;
>> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
>> dprintf("ble_sm_inject_io result: %d\n", rc);
>> }
>>
>> In order to support OOB, I've changed my BLE syscfg configuration to the
>> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
>>
>> BLE_ROLE_CENTRAL: 0
>> BLE_ROLE_OBSERVER: 0
>>
>> BLE_SM_LEGACY: 1
>> BLE_SM_SC: 1
>> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
>> BLE_SM_OOB_DATA_FLAG: 1
>> BLE_SM_MITM: 1
>> BLE_SM_BONDING: 1
>> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
>> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
>> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID
>> |
>> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
>> BLE_STORE_CONFIG_PERSIST: 1
>>
>> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
>> following code to load in a hard-coded TK:
>>
>> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
>> pk.action = event->passkey.params.action;
>> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
>> memcpy(pk.oob, tk, sizeof(tk));
>> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
>> dprintf("ble_sm_inject_io result: %d\n", rc);
>> }
>>
>> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
>> called anymore.
>>
>> So the question is, at what point and where would I call ble_sm_inject_io
>> to insert the TK value?
>>
>> Amr
>>
>>
>> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
>> lukasz.rymanowski@codecoup.pl> wrote:
>>
>> > Hi Amr,
>> >
>> > Nimble does support OOB for Legacy and Secure Connections Pairing.
>> > In both cases you just need to provide OOB (TK) data exchanged by other
>> > means e.g. NFC to the NimBLE stack using "int ble_sm_inject_io(uint16_t
>> > conn_handle, struct ble_sm_io *pkey)".
>> >
>> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
>> >
>> > Hope that helps
>> >
>> > Best
>> > Łukasz
>> >
>> >
>> >
>> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com> wrote:
>> >
>> > > Hello all,
>> > >
>> > > I'm interested in using OOB pairing over NFC to connect my peripheral
>> > > device to a master (an Android phone in this case). The NFC Forum has
>> a
>> > > specification (
>> > >
>> > >
>> >
>> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
>> > > )
>> > > which dictates how two NFC-capable BLE devices can exchange key
>> > > information. As far as I can tell from the specification, for BLE, the
>> > > peripheral can send its temporary key (TK) via NFC to the central.
>> > > Presumably, both parties would then enter that key into their
>> Bluetooth
>> > > stacks and continue the connection process from that point on using
>> just
>> > > BLE.
>> > >
>> > > Regarding this, I have the following question. Using the nimble stack,
>> > how
>> > > can we get the peripheral to
>> > > a) generate a TK and then enter that TK into the stack.
>> > > b) continue the connection from that point forwards?
>> > >
>> > > I noticed that the aforementioned specification document doesn't seem
>> to
>> > > mention BLE Secure Connections - the TK is an aspect of BLE legacy
>> > pairing.
>> > > Does anyone know if there is a version of the standard that works with
>> > BLE
>> > > Secure Connection keys? Perhaps the assumption is that NFC pairing
>> > provides
>> > > the required identify verification and MITM protection that is
>> provided
>> > by
>> > > BLE SC and so BLE Legacy can be used with the same level of security?
>> > >
>> > > Amr
>> > >
>> >
>>
>
Re: Mynewt Nimble OOB pairing
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Amr,
I would call it on gap connected event. Then OOB data are stored and SM can
present/use OOB flag during pairing.
Best
Lukasz
On Fri, Apr 26, 2019, 18:57 Amr Bekhit <am...@gmail.com> wrote:
> Hi Łukasz,
>
> Thanks for your reply. Where and when should the call to ble_sm_inject_io
> take place? In my current setup, I had configured my device to use passkey
> pairing, but for testing purposes, was hardcoding the passkey. The BLE
> stack was requesting the passkey by calling the GAP event callback with
> event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the passkey
> as follows:
>
> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> pk.action = event->passkey.params.action;
> pk.passkey = 123456;
> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> dprintf("ble_sm_inject_io result: %d\n", rc);
> }
>
> In order to support OOB, I've changed my BLE syscfg configuration to the
> following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
>
> BLE_ROLE_CENTRAL: 0
> BLE_ROLE_OBSERVER: 0
>
> BLE_SM_LEGACY: 1
> BLE_SM_SC: 1
> BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
> BLE_SM_OOB_DATA_FLAG: 1
> BLE_SM_MITM: 1
> BLE_SM_BONDING: 1
> BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
> BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
> BLE_STORE_CONFIG_PERSIST: 1
>
> I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
> following code to load in a hard-coded TK:
>
> if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
> pk.action = event->passkey.params.action;
> uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
> memcpy(pk.oob, tk, sizeof(tk));
> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> dprintf("ble_sm_inject_io result: %d\n", rc);
> }
>
> However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
> called anymore.
>
> So the question is, at what point and where would I call ble_sm_inject_io
> to insert the TK value?
>
> Amr
>
>
> On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
> lukasz.rymanowski@codecoup.pl> wrote:
>
> > Hi Amr,
> >
> > Nimble does support OOB for Legacy and Secure Connections Pairing.
> > In both cases you just need to provide OOB (TK) data exchanged by other
> > means e.g. NFC to the NimBLE stack using "int ble_sm_inject_io(uint16_t
> > conn_handle, struct ble_sm_io *pkey)".
> >
> > For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
> >
> > Hope that helps
> >
> > Best
> > Łukasz
> >
> >
> >
> > On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com> wrote:
> >
> > > Hello all,
> > >
> > > I'm interested in using OOB pairing over NFC to connect my peripheral
> > > device to a master (an Android phone in this case). The NFC Forum has a
> > > specification (
> > >
> > >
> >
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> > > )
> > > which dictates how two NFC-capable BLE devices can exchange key
> > > information. As far as I can tell from the specification, for BLE, the
> > > peripheral can send its temporary key (TK) via NFC to the central.
> > > Presumably, both parties would then enter that key into their Bluetooth
> > > stacks and continue the connection process from that point on using
> just
> > > BLE.
> > >
> > > Regarding this, I have the following question. Using the nimble stack,
> > how
> > > can we get the peripheral to
> > > a) generate a TK and then enter that TK into the stack.
> > > b) continue the connection from that point forwards?
> > >
> > > I noticed that the aforementioned specification document doesn't seem
> to
> > > mention BLE Secure Connections - the TK is an aspect of BLE legacy
> > pairing.
> > > Does anyone know if there is a version of the standard that works with
> > BLE
> > > Secure Connection keys? Perhaps the assumption is that NFC pairing
> > provides
> > > the required identify verification and MITM protection that is provided
> > by
> > > BLE SC and so BLE Legacy can be used with the same level of security?
> > >
> > > Amr
> > >
> >
>
Re: Mynewt Nimble OOB pairing
Posted by Amr Bekhit <am...@gmail.com>.
Hi Łukasz,
Thanks for your reply. Where and when should the call to ble_sm_inject_io
take place? In my current setup, I had configured my device to use passkey
pairing, but for testing purposes, was hardcoding the passkey. The BLE
stack was requesting the passkey by calling the GAP event callback with
event->type = BLE_GAP_EVENT_PASSKEY_ACTION. I was then passing the passkey
as follows:
if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
pk.action = event->passkey.params.action;
pk.passkey = 123456;
rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
dprintf("ble_sm_inject_io result: %d\n", rc);
}
In order to support OOB, I've changed my BLE syscfg configuration to the
following (modified SM_IO_CAP, SM_OOB_DATA_FLAG and SM_MITM):
BLE_ROLE_CENTRAL: 0
BLE_ROLE_OBSERVER: 0
BLE_SM_LEGACY: 1
BLE_SM_SC: 1
BLE_SM_IO_CAP: BLE_HS_IO_NO_INPUT_OUTPUT
BLE_SM_OOB_DATA_FLAG: 1
BLE_SM_MITM: 1
BLE_SM_BONDING: 1
BLE_SM_OUR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
BLE_SM_THEIR_KEY_DIST: BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID |
BLE_SM_PAIR_KEY_DIST_SIGN | BLE_SM_PAIR_KEY_DIST_LINK
BLE_STORE_CONFIG_PERSIST: 1
I've tried replacing the code in BLE_GAP_EVENT_PASSKEY_ACTION with the
following code to load in a hard-coded TK:
if (event->passkey.params.action == BLE_SM_IOACT_OOB) {
pk.action = event->passkey.params.action;
uint8_t tk[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
memcpy(pk.oob, tk, sizeof(tk));
rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
dprintf("ble_sm_inject_io result: %d\n", rc);
}
However, it appears that BLE_GAP_EVENT_PASSKEY_ACTION is now not being
called anymore.
So the question is, at what point and where would I call ble_sm_inject_io
to insert the TK value?
Amr
On Fri, 26 Apr 2019 at 14:16, Łukasz Rymanowski <
lukasz.rymanowski@codecoup.pl> wrote:
> Hi Amr,
>
> Nimble does support OOB for Legacy and Secure Connections Pairing.
> In both cases you just need to provide OOB (TK) data exchanged by other
> means e.g. NFC to the NimBLE stack using "int ble_sm_inject_io(uint16_t
> conn_handle, struct ble_sm_io *pkey)".
>
> For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
>
> Hope that helps
>
> Best
> Łukasz
>
>
>
> On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com> wrote:
>
> > Hello all,
> >
> > I'm interested in using OOB pairing over NFC to connect my peripheral
> > device to a master (an Android phone in this case). The NFC Forum has a
> > specification (
> >
> >
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> > )
> > which dictates how two NFC-capable BLE devices can exchange key
> > information. As far as I can tell from the specification, for BLE, the
> > peripheral can send its temporary key (TK) via NFC to the central.
> > Presumably, both parties would then enter that key into their Bluetooth
> > stacks and continue the connection process from that point on using just
> > BLE.
> >
> > Regarding this, I have the following question. Using the nimble stack,
> how
> > can we get the peripheral to
> > a) generate a TK and then enter that TK into the stack.
> > b) continue the connection from that point forwards?
> >
> > I noticed that the aforementioned specification document doesn't seem to
> > mention BLE Secure Connections - the TK is an aspect of BLE legacy
> pairing.
> > Does anyone know if there is a version of the standard that works with
> BLE
> > Secure Connection keys? Perhaps the assumption is that NFC pairing
> provides
> > the required identify verification and MITM protection that is provided
> by
> > BLE SC and so BLE Legacy can be used with the same level of security?
> >
> > Amr
> >
>
Re: Mynewt Nimble OOB pairing
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Amr,
Nimble does support OOB for Legacy and Secure Connections Pairing.
In both cases you just need to provide OOB (TK) data exchanged by other
means e.g. NFC to the NimBLE stack using "int ble_sm_inject_io(uint16_t
conn_handle, struct ble_sm_io *pkey)".
For Secure Connection make sure to set MYNEWT_VAL BLE_SM_SC to 1.
Hope that helps
Best
Łukasz
On Thu, 25 Apr 2019 at 22:19, Amr Bekhit <am...@gmail.com> wrote:
> Hello all,
>
> I'm interested in using OOB pairing over NFC to connect my peripheral
> device to a master (an Android phone in this case). The NFC Forum has a
> specification (
>
> https://nfc-forum.org/our-work/specifications-and-application-documents/application-documents/
> )
> which dictates how two NFC-capable BLE devices can exchange key
> information. As far as I can tell from the specification, for BLE, the
> peripheral can send its temporary key (TK) via NFC to the central.
> Presumably, both parties would then enter that key into their Bluetooth
> stacks and continue the connection process from that point on using just
> BLE.
>
> Regarding this, I have the following question. Using the nimble stack, how
> can we get the peripheral to
> a) generate a TK and then enter that TK into the stack.
> b) continue the connection from that point forwards?
>
> I noticed that the aforementioned specification document doesn't seem to
> mention BLE Secure Connections - the TK is an aspect of BLE legacy pairing.
> Does anyone know if there is a version of the standard that works with BLE
> Secure Connection keys? Perhaps the assumption is that NFC pairing provides
> the required identify verification and MITM protection that is provided by
> BLE SC and so BLE Legacy can be used with the same level of security?
>
> Amr
>