BLE Security - Eavesdropping and pairing

[parco]

My use case involves buttonless beacons that should only be connected to by authenticated users on their mobile device (Android / iOS).

Once connected, these beacons will be sending and receiving confidential information, and should not be able to be eavesdropped.

Our idea is to use the beacon's advertised ID, check with our server to make sure the authenticated user has access to that specific beacon ID, and then give them some pass code.

Would this be considered OOB pairing?

What would be the most secure way to implement this?

[endnode]

Yes, you could use such OOB key generation (= from some static known string such as S/N, ID, MAC... and some master key) and provision it to Security Manager layer of BLE stacks on both sides. The drawbacks are: not all devices support OOB in this way and of course once your master key (used for diversification in each "beacon") leaks you are doomed, whole installation is broken. But still this is the way used for secure devices' provisioning for years in billions (SIM cards, payment cards...) so you might go that way.

The the biggest problem in this scheme is probably "device" provisioning. That is typically done during manufacturing process and as there must be master key involved you have problem if that is not done in 100% secure place. Some people are trying to solve this problem by optimized personalization jig with built-in HSM (Hardware Security Module) or similar device which derives the keys securely inside and the only thing which could leak (e.g. if someone on the manufacturing floor would put some interceptor o JTAG/SWD lines used to provision FW and data to nRF5x chips on your device) are derived keys for each device. Not perfect but still better then nothing. If you want to make one more step then you need to provision the device in high-security manufacturing line (= only authorized personel can go inside, facility is certified, highly monitored etc. - the example would be EMV card perso facility) or simply have this just pre-provisioned and then put final keys in later stage (e.g. before you ship the things to distribution channel but that is usually already inside packaging so quite costly to handle).

Technically diversification is easy: you choose some security scheme (typically some NIST approved or you get inspiration in banking/telco world), generate master key, store i securely and then only "public" part (S/N or MAC or whatever) is read from the device (or generated randomly outside the device) and key(s) are generated. Finally you put it into UICR or other NVM place which is protected against read-back (if you also generate diversifier outside you need to store it inside the chip as well) and you are more or less done.

Final warnings:

• nRF51 NVM protection is broken so storing anything sensitive inside that chip is almost useless.
• nRF52 protection holds for the moment but you never know and it's generic purpose ARM Cortex-M chip design without any special temper-proof features so if gain of cracking the particular key is high for the attacker he/she will succeed (sooner then later).
• Whatever "public" string you choose (nRF5x S/N or other string) it is easily spoofable so you need to be sure that you don't give up diversified keys just to anyone who say "I'm your device XYZ".

[parco]

What an excellent overview of some possibilities, thanks! I do have some followup questions:

You mention to chose some NIST approved scheme, is there one that's included or works nicely with nrf52 SDK?

If I use the S/N as the "non-secret" part. I would use the master key and this S/N to generate another secret key, which I would load into the protected NVM, and in a secure database. Now if the user wants to connect to a beacon, they make a server request and ask for this S/N's secret key, which they pass to the device. The device will then check to make sure this secret key matches the one in NVM, and voila, we can bond. Am I getting this right?

Is it okay to be passing the secret key from the server to client device (Android / iOS), is there a better way to do this part?

[endnode]

Firstly: this is not the topic for 500-character crash course on the forum. If you hear about these things for the first time you will need someone closer to you to guide you or spend few full days of googling and reading.

To your questions:

• Usual architecture how it is done consists of 3 stages: one master key to whole infrastructure (or batch of devices), typically loaded to HSM module and never leaving the backend => that generates diversified "device" master keys which are loaded to each device (in case you break one of them you can only clone it but cannot re-create keys for other devices) but again this key is never used directly or exposed, it only sits in the device and is used for last stage => which is session key generation with some kind of mutual or one-way authentication. Only then data are flowing through "secure channel". Just google these terms... (1/x)

[endnode]

(2/x)

• So I do repeat: these keys are not passwords or passphrases, they are never exchanged in clear. If you want to authenticate you perform some cryptographical operation on top of some random data and this proofs (to someone who has the same key) that you are genuine holder of the credential.
• When it comes to technical ways how to do these key derivations, secure channel protocols etc. there are many more or less verified public scheme. To get inspiration here are some documents to read (it took me 2 minutws to google them): NIST recom. for key derivation, EMV CPS, example of EMV key management implementation

[endnode]

(3/3)

So yes, in your case you would distribute "device" keys to mobile apps (which already makes it seriously vulnerable because cracking iOS or Android app data storage seems to be pretty routine job - if the data are really valuable like keys from your bitcoin valet or banking account;) and then mobile device would use these "device" keys to authenticate (both ways) with BLE device and only then you could communicate securely.

• I'm confused by term "OOB" which is specifically used in BLE context with LongTermKey distribution in BLE SM layer. Then you can forget about secure channel part which I was describing because if you want to use BLE built-in security and your stack supports OOB key import then this does the final part for you. Again "OOB" key is some device specific "master" key which is never sent over the link in clear, just used to derive session specific keys.