BLE Security - Eavesdropping and pairing

Question

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 · Accepted Answer

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".

BLE Security - Eavesdropping and pairing

Top Replies