Android application and Passkey

[while(1)]

nrf52832.

SDK14.2

Segger ES V3.34a

This question is probably best suited to an android forum (possibly).

We have a characteristic which is writable. When written to the peripheral asks our in house application to enter the passkey.  The setting for the characteristic are:

BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&cus_init.brand_char_attr_md.cccd_write_perm);
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cus_init.brand_char_attr_md.read_perm);
BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&cus_init.brand_char_attr_md.write_perm);

and Security setting...

#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 1 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 0 /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_DISPLAY_ONLY /**< No I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size. */

This works great.  We only get prompted for the passkey when we try to write to it and the App auto populates the Passkey.

BUT.

On some Android phones/tablets there is a variation in how the Pairing Request is dealt with, sometimes it's in the task bar or pops up a window to enter the Passkey.

Are there any alternatives for 'write' protection or have experienced the same thing and found a fix or workaround in the Android App?

I have also noticed this with nRF Connect Application.  On my Samsung Tablet I get a popup with a keypad but on my Oneplus3 phone the pairing request is in the task bar.

I would appreciate anybody's  thoughts or ideas.

[while(1)]

Also

The peripheral S132 only has LEDs, no screen or buttons, ideally we don't want to use NFC.

[Hung Bui]

Hi Paul, 

Please correct me if I'm wrong, my understanding is that on some phones you can manage to populate the passkey and there was no dialogue/pop-up  ? 

Or your question is how to deal with different way of showing the text box either in pop-up or taskbar dialogue ? 

I'm unfortunately not Android expert, but in our library we provided this onPairingRequestReceived() function. That you can use to enter the pin, but I think the end user still need to click OK. 

[while(1)]

Hi Hung Bui,

On some phones we can intercept the pairing request and populate the Passkey, without the user seeing.  Although some phones won't let us do this.  It's an inconsistency in security.  This was always possible on older versions, but newer versions seem to be locking down on this.  Does this code work in all cases?  I'll get our app expert to take at look at it.  

We want a way to prevent anyone just writing to our characteristics and for our app to auto populate the passkey, without the user seeing it, ideally.  Keeping the passkey secret would be nice.

Is there a different way to achieve what we want, i appreciate  the above method is not secure as using NFC for example, but it would be a way of preventing someone with 'nRFConnect' being a nuisance.  The data is not sensitive, it purely to stop nuisance attacks.

[while(1)]

Or, is it possible to have authorisation after connection, where the App has to supply the key without the user knowing, maybe on a time out?

[Hung Bui]

Hi Paul, 
Please be aware that passkey pairing is not considered secured. It would take much less than a second to decode it (compute all 999999 possibilities). Any sniffer can decode it. I don't see any benefit for security here, especially when you used a fixed passkey. 
If you want something secured you would need to use LE Secure connection instead of legacy pairing (not all old phones support this, requires BLE 4.2) 
One option you can think of is to have an extra layer of security on top of Bluetooth pairing. For example, after each connection establishment, your characteristic would generate a random value. The app on the phone need to read this and write a correspondent (using a hardcoded secret key and the random value) value back to the characteristic. After that your device start to operate. This is very simple and there is a chance that if they can crack the code on one device/app, they would be able to crack all other devices. But it's still beter than the "hidden passkey" approach.