Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Implementing BLE security for the application

Greetings to Nordic team!

I would like to provide BLE security for my application (to my BLE Peripheral device). I am planning to apply the following features such as

1. Generate a 128 bit key for my BLE Peripheral and share this via a secure channel (not important here) to central device. (As I can use here the passkey or 6 digit pin but inorder to improve the security I would suggeste to use 128 bit key)

2. Central device initiates pairing, encrypt and distribute the key.

Is it possible to implement this security type? If so how can I generate a 128 bit key key for my peripheral device? and is it possible for a central device to implement pairing by reading this 128 bit value ? I am really not good in BLE and BLE Security...looking forward to hearing from you.

Thanks and Regards,

Sreejith

Parents
  • Assuming you have control over both devices, it seems pairing with OOB (out-of-band) could be the perfect fit here. That is part of the BLE standard and can be used to get better security than the 6 digit passkey.

  • Hi Emil,

    Thank you. Ok I would go for pairing with OOB but can I include MITM at the same time? I have no idea that both OOB and MITM can include within my application. I would like to to authenticate/Pair  via shared secrets? This is I am looking for.

    Thanks and Regards,

    Sreejith

  • I don't understand exactly what you mean when you say "both OOB and MITM can include within my application". OOB stands for "out of band" and "MITM" stands for man-in-the-middle. Exchanging keys out of band is exactly one way of being resistant against man-in-the-middle attacks, since the idea is that any potential man cannot be in the middle in this scenario.

    The Bluetooth standard does not specify which out-of-band mechanisms that can be used, so whatever way you implement this will be fine and allowed.

    I'm not familiar with the Peer Manager, but if you use the soft device api directly then you call the method sd_ble_gap_auth_key_reply to set OOB key, if you use legacy pairing (not LESC). The only thing you need to make sure about the key itself is that the same 128-bit secret shared key is input on both the peripheral and central side. Any attacker sniffing the connection will not be able to decrypt the following packets since this 128-bit key is used for AES encryption. See this flowchart how it's done on the central side. Note that you need to specify the correct parameters to sd_ble_gap_authenticate. Set bond=1 (assuming you want bonding), mitm=1, lesc=0, oob=1.

    The bonding process will then result in a standard Bluetooth bond, with a newly generated LTK.

Reply
  • I don't understand exactly what you mean when you say "both OOB and MITM can include within my application". OOB stands for "out of band" and "MITM" stands for man-in-the-middle. Exchanging keys out of band is exactly one way of being resistant against man-in-the-middle attacks, since the idea is that any potential man cannot be in the middle in this scenario.

    The Bluetooth standard does not specify which out-of-band mechanisms that can be used, so whatever way you implement this will be fine and allowed.

    I'm not familiar with the Peer Manager, but if you use the soft device api directly then you call the method sd_ble_gap_auth_key_reply to set OOB key, if you use legacy pairing (not LESC). The only thing you need to make sure about the key itself is that the same 128-bit secret shared key is input on both the peripheral and central side. Any attacker sniffing the connection will not be able to decrypt the following packets since this 128-bit key is used for AES encryption. See this flowchart how it's done on the central side. Note that you need to specify the correct parameters to sd_ble_gap_authenticate. Set bond=1 (assuming you want bonding), mitm=1, lesc=0, oob=1.

    The bonding process will then result in a standard Bluetooth bond, with a newly generated LTK.

Children
  • Hi Emil,

    I'm not familiar with the Peer Manager, but if you use the soft device api directly then you call the method sd_ble_gap_auth_key_reply to set OOB key, if you use legacy pairing (not LESC). The only thing you need to make sure about the key itself is that the same 128-bit secret shared key is input on both the peripheral and central side. Any attacker sniffing the connection will not be able to decrypt the following packets since this 128-bit key is used for AES encryption. See this flowchart how it's done on the central side. Note that you need to specify the correct parameters to sd_ble_gap_authenticate. Set bond=1 (assuming you want bonding), mitm=1, lesc=0, oob=1.

    Exactly this is the method which I would like to include within my application with Legacy Pairing. Is there any example which I can refer for this example in the SDK?

    Thanks Emil for the response and for your time.

    with regards,

    Sreejith

Related