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 >> >> > > >> >> > >> >> >> > >> >
