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;)

[Petter Myhre]

The SoftDevice implements the security features that are in the Bluetooth specification. Then you can use the Peer Manager to manage these features. In general we recommend to use the Peer Manager.

It is difficult to suggest a "best" method without knowing more about your application.

What kind of device are you making? Does it have any input? Buttons? Keypad? NFC? Does it have any output? LEDs? Screen? NFC? What about its peers? What kind of I/O do they have? Do they peers have support for LESC pairing? Will you be pairing the devices in a safe environment?

You say you want to protect against MITM attacks, what about passive eavesdropping? Is that a concern?

[MarcoTull]

I am using multiples peripherals to record temperature variations and two central to connect to each peripheral (one per time not multiple connections), The only input for my modules is the temperature sensor, and for my central the only input is the data coming from the peripheral over BLE, I suppose it supports LESC because I am using central and peripheral roles using the SDK13. I would like to protect my devices from malicious attacks and try to keep them as safe as possible. Is not eavesdropping the same that sniffing? or similar to MITM? is there any example or guideline to add peer manager to my devices?

[Petter Myhre]

My mistake, I didn't see sniffers in the parentheses there.

If you don't have any inputs you have two options (from a Bluetooth perspective):

-Legacy pairing with Just Works. This does not offer protection against MITM or passive eavesdropping during the pairing process, but if there is no attack during the pairing process the encryption is secure.

-LESC pairing with Just Works. Offers protection against passive eavesdropping, but not against MITM during the pairing process. If there is not attack during the pairing process the encryption is secure.

[MarcoTull]

Hey, Petter thanks for answering, now it is a little clearer and easier to take the route to follow. Last two quick questions. In the case the LESC parting with Just Works, it protects against eavesdropping, does not it make harder a MITM attack?

I ask it because I had done reverse engineering to BLE devices in the past using a sniffer.

Second question any example with LESC in nRF5 SDK?