This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What could be better for security encryption and authentication : passkey vs PKI

Hi guys

I am wondering what could be better for my system:

Multiples nRF52 central and peripherals (uart input/uart output to simulate keyboard and display)

SDK 13

Required: MITM, eavesdrop protection

What is more recommended use peer manager with random numeric comparison similar to LESC multi role example or a PKI with a 128bit static pre shared key?

Parents
  • Hi,

    Which one you prefer is the deciding factor here. Both LE Secure Connections and pre-shared keys are equally secure and offer MITM and eavesdrop protection. LESC is more flexible since it allows units to be paired after the devices are shipped, while the pre-shared key approach is simpler for an end users who just want things to work out of the box.

    Best regards,
    Rune Holmgren

  • Hi Holmgren, thanks for the reply.

    LESC using random passkey and pre-shared key both can offer protection against passive eavesdropping and MITM during connection/reconnection between a central and peripheral?

    is there any example on the SDK with pre-shared key approach?

  • Hi,

    Yes, both approaches offer MITM protection when a central and peripheral connect for the first time and pair and bond (All BLE bonds are secure once the bonding is complete, so reconnection is not something you need to worry about).

    A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing. The nRF5 SDK has an example showing OOB pairing over NFC (examples\ble_peripheral\experimental\ble_app_hrs_nfc_pairing), so if you have a look at how the pairing in that example works and strip away the NFC specific parts you have a good idea of how this should be done. You may also want to read up on the SoftDevice documentation. sd_ble_gap_lesc_oob_data_set seems like a good place to start.

    A point I forgot to mention in my last message is that you should consider the logistics of your manufacturing. LESC is an advantage in that all devices you make are identical and can be put two and two in their boxes without any further logistics. With pre-shared keys, you need to ensure that each pair of devices gets flashed with a slightly different firmware and placed as a pair in their box.

    Best regards,
    Rune Holmgren

Reply
  • Hi,

    Yes, both approaches offer MITM protection when a central and peripheral connect for the first time and pair and bond (All BLE bonds are secure once the bonding is complete, so reconnection is not something you need to worry about).

    A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing. The nRF5 SDK has an example showing OOB pairing over NFC (examples\ble_peripheral\experimental\ble_app_hrs_nfc_pairing), so if you have a look at how the pairing in that example works and strip away the NFC specific parts you have a good idea of how this should be done. You may also want to read up on the SoftDevice documentation. sd_ble_gap_lesc_oob_data_set seems like a good place to start.

    A point I forgot to mention in my last message is that you should consider the logistics of your manufacturing. LESC is an advantage in that all devices you make are identical and can be put two and two in their boxes without any further logistics. With pre-shared keys, you need to ensure that each pair of devices gets flashed with a slightly different firmware and placed as a pair in their box.

    Best regards,
    Rune Holmgren

Children
No Data
Related