Hide Characteristics values before Bound

[code_hard]

Hello,

I am going my project with NRG51822 in SDK 11. I build a android app that can connect to my device and access vendor specific service.

My device dedicates one button for BLE connection, and it will trigger limited advertising on button pressed. Android could connect to device in 30 secs after BLE button pressed, and it will perform bond procedure after "Just Works" pairing.

I want characteristics that in vendor specific service can not be accessible before bound, what should I do? Does any example in SDK 11 has the similar procedure that I could refer to?

Regards,

code_hard

[Roger Clark]

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.

[code_hard]

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.

[Roger Clark]

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)

[run_ar]

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.