Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 6 months ago.
Should BLE_SecureHeartRate work on nRF51-DK & if so, what am I doing wrong, please?
I added some more debug output to BLE_SecureHeartRate and forked it at:
Import programQ_BLE_SecureHeartRate
Fork of BLE_SecureHeartRate : should this 'work' i.e. require a secure connection on an nRF51-DK? Hopefully I'm just missing something obvious - or is this broken?
Last commit 27 May 2016 by 
Tom Gilbert
I'm trying the following params to SecurityManager.init on an nRF51-DK, based on the assumption the required capabilities are for the nRF51-DK device, rather than the Nexus 6P I'm connecting from.
bool enableBonding = true;
bool requireMITM = true;
uint8_t pass[6] = {0x31, 0x32, 0x33, 0x34, 0x35, 0x36};
ble.securityManager().init(enableBonding, requireMITM, SecurityManager::IO_CAPS_NONE, pass);
I'd hoped this code would cause the nRF Toolbox app to request a passcode on the phone, matching the one I have hardcoded in the mbed code: "123456".
Instead nRF Toolbox HRM connects and shows the bpm without any passcode being required.
Example debug output from the nRF51-DK running Q_BLE_SecureHeartRate:
Connected to 3! OK: getLinkSecurity status: NOT_ENCRYPTED OK: getLinkSecurity status: NOT_ENCRYPTED ...then when explicitly disconnected... Disconnected from 3!
Hopefully I'm missing some really obvious step...or is a SoftDevice update required, or something? Thanks!
1 Answer
8 years, 6 months ago.
I just happened to have looked at this last week, and imo it is pretty poorly documented (if at all):
First of all, it is easier to type your pass as
uint8_t pass[6] = {'1', '2', '3', '4', '5', '6'};
(I think "123456" also works, although then you also got as 7th character a \0), exactly same as you have, just bit more readable imo.
Now to actually answer your question: I think SecurityManager::IO_CAPS_NONE means it thinks since you have no display, your device can't show a key for the user to enter, so it will do an unprotected connection (although it does have something different compared to not calling it at all, if I don't put it there a Windows phone can't connect to it, but if I do put it there i can connect with a Windows phone without password).
So as in the example, it should work if you put SecurityManager::IO_CAPS_DISPLAY_ONLY instead.
Hi Erik, thanks for answering. I'd tried a few combinations already , but tried exactly as you suggest above with SecurityManager::IO_CAPS_DISPLAY_ONLY (& also reverted to the clearer method of specifying the password). I'm afraid there is still no security popup on either my Nexus 6P or an iPhone 5S, the nRF Toolbox app HRM is able to connect through and see the bpm w/o any password being required.
posted by 24 May 2016I'll try to have a look with my phone in a few days if you haven't solved it by then.
posted by 24 May 2016I just tried a yotta-built version (w minor changes to support minar & remove main): same outcome. API seems odd for the static password case: why should the peripheral care how the password is gathered at the other end? Shouldn't peripheral just express 'I need a password' & the other end be responsible for gathering that password (or not) however seems appropriate?
posted by 25 May 2016With my Lumia 640 + RedBearLabs NRF51822 I imported your example and compiled it without any changes:
It asks for a pass key, and after inputting 1-2-3-4-5-6:
Connected to 3! OK: getLinkSecurity status: NOT_ENCRYPTED Input passKey: 1 2 3 4 5 6 OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS Security success OK: getLinkSecurity status: ENCRYPTED OK: getLinkSecurity status: ENCRYPTED OK: getLinkSecurity status: ENCRYPTED OK: getLinkSecurity status: ENCRYPTED OK: getLinkSecurity status: ENCRYPTED OK: getLinkSecurity status: ENCRYPTED Disconnected from 3!
After that I disconnected from it and removed it from my phones Bluetooth devices so it would ask me again for the pass, and this time I entered 1-1-1-1-1-1:
Connected to 3! OK: getLinkSecurity status: NOT_ENCRYPTED Input passKey: 1 2 3 4 5 6 OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS OK: getLinkSecurity status: ENCRYPTION_IN_PROGRESS Security failed Disconnected from 3!
How on earth your phone is connecting to it without a passcode is weird for me. Are you 100% sure you are loading the latest version to your NRF device? You can try from the compile dropdown menu choose compile-all (really shouldn't matter, but still worth a shot I guess). I compile it as 'default' (so no FOTA stuff).
Finally, BLE doesn't really care how the password is given to the user to enter, I think it is more a way to classify them, where a 'DISPLAY' device can tell a user a password but cannot ask a user to enter it for example (and that can be via a display, or the manual, a speaker, etc). Although I am also not yet completely clear regarding everything to get the different BLE security options functional.
posted by 26 May 2016Hi Erik, I tried again to confirm, using first IO_CAPS_DISPLAY_ONLY and then IO_CAPS_KEYBOARD_DISPLAY. I changed the advertised name to make sure the s/w (build using 'compile-all') was really making it over to the device. Also rebooted both phones (Android, iOS) as best attempt to make sure any cached BLE information cleared. I know this works for Android, at least to the extent of clearing the cache of UUIDs for a given MAC.
Tried this on both nRF51-DK and a RedBearLab BLE Nano.
nRF Toolbox 1.16.3 (Android) and 3.0.1 (iOS), HRM, both connect straight through & show the bpm. Very odd!
One oddity about the online compiler is that the BLE_API library shows as 'not the latest version' but the update button is disabled. The link through to the library shows it appears to be at the latest version.
I am replying here since otherwise you don't get a notification and you might very well miss it:
With my Lumia 640 + RedBearLabs NRF51822 I imported your example and compiled it without any changes:
It asks for a pass key, and after inputting 1-2-3-4-5-6:
After that I disconnected from it and removed it from my phones Bluetooth devices so it would ask me again for the pass, and this time I entered 1-1-1-1-1-1:
How on earth your phone is connecting to it without a passcode is weird for me. Are you 100% sure you are loading the latest version to your NRF device? You can try from the compile dropdown menu choose compile-all (really shouldn't matter, but still worth a shot I guess). I compile it as 'default' (so no FOTA stuff).
Finally, BLE doesn't really care how the password is given to the user to enter, I think it is more a way to classify them, where a 'DISPLAY' device can tell a user a password but cannot ask a user to enter it for example (and that can be via a display, or the manual, a speaker, etc). Although I am also not yet completely clear regarding everything to get the different BLE security options functional.
posted by Erik - 26 May 2016