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 <[email protected]> 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 <[email protected]> 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 <
> > [email protected]> 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 <
> >> [email protected]> 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 <[email protected]> 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 <
> >> >> [email protected]> 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 <[email protected]>
> >> 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
> >> >> > >
> >> >> >
> >> >>
> >> >
> >>
> >
>
