Hide Characteristics values before Bound

RE: Hide Characteristics values before Bound

run_ar — Fri, 03 Feb 2017 10:29:50 GMT

If you have a display you could probably support LE secure connections and use numeric comparison for authentication. And if the peer doesn't support LE fall back to using Legacy pairing with MITM/passkey. Or do what Roger Clark suggest.

RE: Hide Characteristics values before Bound

Roger Clark — Fri, 03 Feb 2017 04:07:43 GMT

You could use the NONCE method, but there is problem with this on the nRF51, as the read protection hardware has a known bug, which can be exploited to read out any private keys that are in your firmware.

So if you want anything to be secure you'd need to use the nRF52

NFC is more secure but currently its not available on iOS as Apple don't allow apps to use it (Apple site security concerns about their Apple Pay system if they allow other Apps to use the NFC, but speculation is that this is a ploy to keep companies like PayPal etc from using the NFC, and reducing Apple Pay's market share)

So if you have to be secure, and multi platform, I'd suggest you go for nRF52 + public key encryption. Especially if you do the key testing and generation on your server rather than your App and use SSL for all comms. (apps can be hacked to extract keys - e.g. on iOS JailBroken devices)

RE: Hide Characteristics values before Bound

code_hard — Fri, 03 Feb 2017 03:57:38 GMT

Thank you Roger Clark and run_ar,

You are right, I can't not against MITM attack right now. so it means that I need using OOB procedure to pass key by LCD either change to nRF52 solution by NFC? It is a big design change, I not sure. I need to think about it.

Thanks for your advice.

RE: Hide Characteristics values before Bound

Roger Clark — Thu, 02 Feb 2017 10:04:45 GMT

There is a tutorial about secure paring using a NONCE and the RND, I think that may be a better way to handle your security.

RE: Hide Characteristics values before Bound

run_ar — Thu, 02 Feb 2017 09:48:46 GMT

@code_hard
Yes, that sounds about right. But not sure about 4. I guess you might also want to be able to reconnect to the previously known device. And as Roger Clark says you won't know exactly which device is connecting to you when using just works, so you might want to consider using authentication (just works is unauthenticated).

RE: Hide Characteristics values before Bound

Roger Clark — Thu, 02 Feb 2017 04:55:42 GMT

Do you want to hide a service or a Characteristic?

They are not the same.

Unless you are doing some sort of authenticated pairing, I'm not sure how this provides any more security.

You initially said that your device will not advertise until the button is pressed, and hence nothing will be able to connect to the device prior to the button press as the Central device (e.g. Android phone), won't know what to connect to as it will not have the mac address of the Peripheral device.

When you press the button, you have to hope that your Android application detects the advertising before any other device which may be listening, otherwise the other device will connect first and go through the same process as your Android app and prevent your Android app from connecting.

Because of the way BLE frequency hops, the Android app is not guaranteed to receive the first transmitted advertisement.

RE: Hide Characteristics values before Bound

code_hard — Thu, 02 Feb 2017 02:41:44 GMT

Dear run_ar,

Thank you for reply, allow me to repeat your suggestion on list.

Android pair device with "Just Works". Android perform service discover procedure and can not discover vendor service at that time.
Android perform bond procedure successful, then device add vendor service and send SCCD indication to android.
Android perform service discover procedure again and get updated service list. Now Android could manipulate vendor service.
On Disconnected event occured, device reinitialize SoftDevice module and return to un-updated service and wait for next pair.

I don't want to misunderstand what you mean.

Regards,

code_hard

RE: Hide Characteristics values before Bound

run_ar — Wed, 01 Feb 2017 13:19:55 GMT

So the Android device will do service discovery and then bond if it receives an att error: insufficient authentication (unless the slave sends and SMP request prior to that). I suggest you add the vendor specific service after bonding and send a service changed indication to android to trigger a new service discovery (works as long as the android phone supports service changed indications). Note it's possible to add services, but not remove them. That is you wil have to reinitialize the SD to remove services, but this should only take about 1 ms.

RE: Hide Characteristics values before Bound

Roger Clark — Wed, 01 Feb 2017 10:21:43 GMT

Interesting question.

AFIK. Characteristic(s) details are transferred after the connection has been made.

The advertising packet just contains the service UUID number, and nothing about the characteristics.