nRF51822 secure connection with password

[f.salvatore]

Hi all, i want a security check on connection that permits only to users that have a password to connect to my peripheral device and, particularly, to read/write on services. I'm using SDK 11 but i don't found any mechanism like this. I found only the passkey on bonding, but it's not my request because also without bonding a user can read and write freely on services.

It is possible in BLE standard? How can i do it? It is possible, otherwise, to protect a single service from R/W with a password?

Thank you.

[Ulrich Myhre]

Hi,

There is no way in BLE to provide a password during connection setup. The only option for restricting connections are whitelists, which require a bond with an existing peer. This can be set up in the first connection, and then the peripheral can use whitelist for subsequent connections. The only option to set this up without a prior bond, is to share the address outside of BLE. This can be an address written to UICR during manufacturing, or exchanged through UART, NFC (nRF52 only) or SPI.

To restrict access to attributes, there are multiple choices. You can trust the Bluetooth security level, and set a security restriction on the characteristic itself. This is done with the macros like BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM when you add the characteristic. This requires you to have a security level that matches the requirements. ENC_WITH_MITM requires you to enter a pin code, but this will require you to be able to display the pin code on one side - and enter it on the other. (Search for "Static passkey" on DevZone for other options here).

The other way is to use authorization. If you enable the rd_auth/wr_auth bits when you add a characteristic, you will get an event every time a peer wants to read and/or write the characteristic value. Example. Here you can arbitrarily choose if a peer has access or not, which means you are free to implement your own authentication scheme to grant access. Note that this will severely limit throughput on writing to this attribute, because you have to authorize every request.

So to re-iterate:

• The only way to restrict connections is with whitelisting, which require you to know the address and/or IRK of the peer beforehand.
• There are multiple ways to restrict read/writes. The best one overall is to use BLE security, and make sure that the encryption happens in a safe manner. This would be to either use LE secure connections, or to reduce transmitting power and hold devices close during the bonding process (to limit the possibility for sniffing).

[sbailes]

so is it possible to do the security without the whitelist? Just using the BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM? Or is the whitelist still required? If not, how would you use the SEC_MODE_SET_ENC_WITH_MITM? Where would you put it in the code?

[Ulrich Myhre]

Yes, you can pair and encrypt without bonding, and without the use of whitelist. It's up to you if you want to only whitelist bonded devices. The macro is used to set the access levels (sm and lvl fields) of of attributes, which you have to set when you add a characteristics. Then a peer will get an error when trying to read or write.

[sbailes]

Is it possible to set access levels for DFU? I have tried, but I cannot seem to get it to work. When I added the ENC_WITH_MITM I still had access to the DFU without bonding.

[Ulrich Myhre]

Maybe you should raise this as a new question. If you have set ENC_WITH_MITM on the attribute, it should not be possible to write to it without an MITM-encrypted connection. It doesn't necessarily have to be a bond, but encryption should be required. It is still possible to discover the service though.