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