Which method is recommend for BLE security?

RE: Which method is recommend for BLE security?

Hung Bui — Wed, 25 Oct 2017 12:10:58 GMT

Hi Marco,

You can refer to the \examples\ble_central_and_peripheral\experimental\ble_app_multirole_lesc\ to see how to handle LESC. This message sequence chart would also help.

RE: Which method is recommend for BLE security?

MarcoTull — Wed, 25 Oct 2017 02:33:51 GMT

Hi Hung, I was wondering how can I enable "LESC pairing with Just Works" what settings are required on peer_manager_init?

sec_params.bond           = SEC_PARAMS_BOND;
sec_params.mitm           = SEC_PARAMS_MITM;
sec_params.lesc           = SEC_PARAMS_LESC;
sec_params.keypress       = SEC_PARAMS_KEYPRESS;
sec_params.io_caps        = SEC_PARAMS_IO_CAPABILITIES;
sec_params.oob            = SEC_PARAMS_OOB;
sec_params.min_key_size   = SEC_PARAMS_MIN_KEY_SIZE;
sec_params.max_key_size   = SEC_PARAMS_MAX_KEY_SIZE;

RE: Which method is recommend for BLE security?

Hung Bui — Wed, 18 Oct 2017 08:47:09 GMT

Yes, you can do that. I don't see any reason why it wouldn't work.

RE: Which method is recommend for BLE security?

MarcoTull — Tue, 17 Oct 2017 16:52:38 GMT

Hey Hung thanks for the reply, Is possible integrate the LESC into the BLE blinky example for both sides central a peripheral?

RE: Which method is recommend for BLE security?

Hung Bui — Tue, 17 Oct 2017 08:56:51 GMT

Hi Marco,

Petter is away. I will try to help you.

No, protection against eavesdropping doesn't help increase security against MITM. MITM is about authentication, how can you be sure the device your central talking to is actually the device you looking at ? The scenario is you're using your central device A to pair to a device B, but actually the communication is going to a MITM device, and then that MITM then pair to the device B separately. With Just Work, you have no way of authentication (screen, keyboard etc) when pairing. You can never figure out that you are talking to the wrong guy.

This is different to eavesdropping, where the two device A-B actually talking to each other, the third guy just listen and understand what's transmitting between A-B.

Yes we have this example in the SDK showcasing LESC.

RE: Which method is recommend for BLE security?

MarcoTull — Thu, 12 Oct 2017 19:13:28 GMT

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?

RE: Which method is recommend for BLE security?

Petter Myhre — Thu, 12 Oct 2017 07:06:24 GMT

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.

RE: Which method is recommend for BLE security?

MarcoTull — Wed, 11 Oct 2017 18:08:20 GMT

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?

RE: Which method is recommend for BLE security?

Petter Myhre — Mon, 09 Oct 2017 11:47:56 GMT

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?

RE: Which method is recommend for BLE security?

endnode — Thu, 05 Oct 2017 19:55:18 GMT

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