• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 11504 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114757
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Protecting write characteristic - best option?

r00li

Hi! I have some issues with security and BLE. I have a device (using the nrf51822 and S110 softdevice) that has a custom service with a single read write characteristic. Problem is that I want to protect that characteristic from being written to by just anyone that is around.

This device doesn't have any displays or any other inputs and it's meant to be always powered and installed in a hard to access area. I want the device to be discoverable by anyone and can be connected to by multiple peers (not at the same time). So if the device isn't already connected I want to be able to find it and connect to it. Then of course read and write that characteristic.

But I don't want just anyone to write to that characteristic - I don't mind if anyone reads it (though it's still not ideal). A perfect way would be to use a password protected connection. But if I know anything that can't be achieved with BLE?

So is it possible to give the user some predefined password which would protect the characteristic, and can later be changed if so desired?

  • 0

    What kind of central devices would connect to this device?

  • 0

    Either a phone or some specialized embedded system running linux.

  • 0

    BLE security mode 1 has four security levels, and a connection operate in one of these levels.

    1. No security – No encryption
    2. Unauthenticated pairing with encryption, but no MITM protection
    3. Authenticated pairing with encryption and MITM protection
    4. Authenticated LE Secure Connections pairing with encryption

    Every time two devices connect, the connection operate in security level 1 - no security. Then you perform an authentication procedure or encryption procedure to increase the level of security of the connection.

    With the authentication procedure the higher level of security is achieved by doing unauthenticated or authenticated pairing. Authenticated pairing results in authenticated encryption keys, while unauthenticated pairing results in unauthenticated encryption keys.

    Pairing is authenticating another device, and establishing temporary shared secret keys which can be used to encrypt a link. Bonding is pairing followed by distribution of keys which can be used to encrypt the link in future reconnections. With only pairing the keys are only valid on the current connection, with bonding the keys are typically stored persistently (as a bond) and can be used on subsequent connections.

    With the encryption procedure the higher level of security is achieved by encrypting the connection with encryption keys that are already available (no pairing necessary). This is typically if encryption keys were shared and stored after previously performed bonding. These encryption keys can also be authenticated or unauthenticated and determine the security level.

    It is possible to set a security requirement on a characteristic value, it is also possible to have different security requirements on writes and reads of a characteristic value.

    You want the user to be authenticated before he/she can acccess the characteristic value, so you should set the required security level for writing to level 3.

    To increase the security level of the connection to level 3 you have two options, pairing with Passkey Entry or OOB.

    Passkey Entry normally requires a display or a keyboard, but with our SoftDevices you can set a static passkey, so the device doesn't need any input. This would be similar to a predefined password, only it will be a predefined passkey. This is of course less secure, since the passkey is static. The passkey is also short, only 6 digits, or around 20 bits, which means it provides very limited protection against eavesdroppers during the pairing process. If the attack is not performed during the pairing process, the encryption is secure and confidentiality is achieved.

    With OOB a 128 bit key is normally transferred by some other means, for example by using Near-Field Communcation, but you can also have this static in our SoftDevices. The OOB key is intended to be random, so setting it statically is less secure. A problem is that as far as I know Android and iOS doesn't allow you to set OOB key directly, only through NFC or other.

    If you bond you can store the authenticated keys persistenly and do an encryption procedure on subsequent connections. This will increase the security level to 3, and you will be able to write the characterisitic value.

    In my mind these are the options that are offered to you by the BLE protocol, you can of course (additionally) implement something in the application layer. This blog may not be relevant, but it is an interesting read.

  • 0 in reply to Petter Myhre

    Thanks for the nicely detailed explanation of security in BLE! It's really helpful.

Related