Which method is recommend for BLE security?

[MarcoTull]

Hi,

I am wondering which is the best method for BLE security to avoid MITM, protect the data (sniffers) and limit connection only to allowed devices for a massive number of BLE devices, example 500 > random and new devices.

Peer manager is the recommend for this task? or something like Application-level Security Using the ECB Peripheral?

devzone.nordicsemi.com/.../

info: NRF52 and SDK13

Regards, Marco

[endnode]

BLE Secure Manager layer (which is all what gets implemented in SDK examples because that's the only "standard") is suited for "one to one" (or "few to few") scenarios where only few bonds need to be stored (peer manager works with 8 if I'm not mistaken). Once your initial condition is that you want to have pool of dozens or hundreds of devices which should be able to talk securely to each other then it doesn't scale easily (because even if you use OOB method listed in following list you should store bonding info for each link which can suddenly make kB of data which must be searchable easily on the fly). From high level you have following basic options:

• Use BLE Security Manager with pre-shared AES key (OOB method). It will work and it will be reasonably secure (AES-128 is not broken by any practical attack) until any device (or other way - e.g. from production or internally form the company/team) gets broken and master key is leaked. Then whole infrastructure is broken and you need to recall/reprogram/update...
• Implement something on application layer (either based on symmetric cipher like AES which leads more or less to the same scheme of pre-shared master keys common for the whole infrastructure which compromises it whole once leaked or something based on more modern schemes which are mixing asymmetric and symmetric keys and build some infrastructure - PKI based or other)

Note that while probably second way is recommended from cryptography/security stand point it's not easy to make it correctly and still fast, robust, easy to implement, easy to maintain in the field, easy to produce in the factory... Therefore most of large systems (e.g. which are guarding some top secret things and facilities) are still using simple infrastructure with some secret master AES keys (but all people responsible for it are probably having nightmares about master key leaking almost every night;)