Android application and Passkey

RE: Android application and Passkey

while(1) — Fri, 29 Mar 2019 12:09:09 GMT

Hi Hung Bui,

I used a timeout handler to check a flag set by my password checking routine. If the flag is not set i use this...

ret_code_t err_code;

err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
APP_ERROR_CHECK(err_code);

Which then closes the connection.

This is so simple and does exactly what we need,

Thanks

RE: Android application and Passkey

Hung Bui — Thu, 21 Mar 2019 15:56:43 GMT

Sure no problem. If you need a bit more secure, you can thinking of a public-private key pair. This way you can keep the private key only on the phone or on the cloud and leaving only the public key on the device, making it a little bit safer.

RE: Android application and Passkey

while(1) — Thu, 21 Mar 2019 15:46:26 GMT

Understood.

I will implement this, and let you know and verify your answer too.

Thanks Hung Bui

RE: Android application and Passkey

Hung Bui — Thu, 21 Mar 2019 15:03:08 GMT

My idea is to implement a mechanism so that right after you connect the app to the device (you can do bonding or not doesn't really mater), your app need to read the characteristic to get the random value (nounce ) . From that random value, the app need to use the secret key to generate a hash value and send back to the device using a write. If within 10 seconds (or less) , the app failed to do that or the hash value is not correct, the device will drop the connection. Within that 10 seconds, the device won't operate.

This process will be transparent to the end customer. If you reduce the timeout (instead of 10 seconds) it won't be noticed by the end customer.

RE: Android application and Passkey

while(1) — Thu, 21 Mar 2019 11:14:10 GMT

We don't want the user to have to enter any codes or even press OK ie no bonding.

I think this idea is good

[quote userid="2121" url="~/f/nordic-q-a/44995/android-application-and-passkey/177438"]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. [/quote]

Not sure what you mean by

[quote userid="2121" url="~/f/nordic-q-a/44995/android-application-and-passkey/177438"]After that your device start to operate[/quote]

But what bout this idea?... if this process is not fulfilled within a timeout, the peripheral drops the connection. But as we don't want the user interaction on the App (no bonding) we can't have any security on the writable Characteristics. So we will rely purely on the connection being dropped before anything else can be written. Or am I missing something?

RE: Android application and Passkey

Hung Bui — Wed, 20 Mar 2019 16:22:56 GMT

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.

RE: Android application and Passkey

while(1) — Wed, 20 Mar 2019 16:03:22 GMT

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?

RE: Android application and Passkey

while(1) — Wed, 20 Mar 2019 12:08:44 GMT

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.

RE: Android application and Passkey

Hung Bui — Tue, 19 Mar 2019 14:35:50 GMT

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.

RE: Android application and Passkey

while(1) — Mon, 18 Mar 2019 14:29:50 GMT

Also

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