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 <amrbek...@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.rymanow...@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 <amrbek...@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
> > >
> >
>
