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