Bluetooth Security

[mehmetefe]

Hello Nordic Team,

We are developing a wearable health device using the nRF5340-DK and Zephyr RTOS. As part of the BLE communication design, we intend to use **Security Level 2 (Encryption without MITM protection)** due to the user experience constraints in wearable environments (e.g., no display for passkey entry, etc.).

In our current implementation:

- We start advertising with connectable parameters.
- After connection, we call `bt_conn_set_security(conn, BT_SECURITY_L2);`
- We use GATT services with `BT_GATT_PERM_READ_ENCRYPT | BT_GATT_PERM_WRITE_ENCRYPT`
- We register authentication callbacks but avoid user interaction (no passkey/Numeric comparison) due to product limitations.

Could you please confirm if this approach is **sufficient and secure enough** for typical wearable use-cases like Noira Band, assuming the device is paired with a trusted smartphone app?

Also, do you have **any recommendations** or **best practices** for Level 2 usage in production devices?

Any insights on TRNG usage, bonding persistence, or key storage would also be appreciated.

Thank you very much for your time and support.

Best regards,  
Mehmet Efe Öten  

[Amanda Hsieh]

Hi, 

Check out this course Lesson 5 – Security in Bluetooth LE communication and its exercises. 

Regards,
Amanda H.

[mehmetefe]

Hi Amanda,

Thank you for your response.

I’ve reviewed Lesson 5 and all related links you mentioned in detail. However, the provided materials don't fully address our specific use case: a displayless wearable device using nRF5340 and Security Level 2 (encryption without MITM).

We would greatly appreciate further clarification or official recommendations on the following topics:

1. Whether Security Level 2 is considered sufficient for production-grade wearable devices (e.g., fitness bands) without user interaction.

2. Suggestions regarding TRNG (True Random Number Generator) usage in BLE pairing/bonding.

3. Best practices for bonding and key storage when using Zephyr with the nRF5340.

Our goal is to balance user experience and security, and we’re seeking Nordic's official guidance for this particular scenario.

Thank you very much for your time and support.

Best regards,
Mehmet Efe Öten

[Amanda Hsieh]

mehmetefe said:

Whether Security Level 2 is considered sufficient for production-grade wearable devices (e.g., fitness bands) without user interaction.

You should do a threat model for your use case to answer this question. On the technical side, you should enable LESC only mode. That should be the default on the latest NCS. Check BT_SMP_SC_PAIR_ONLY config. Without OOB or IO capabilities, it would still land on level 2; however, it protects against eavesdropper attack, unlike legacy pairing, which should not be used.

mehmetefe said:

Suggestions regarding TRNG (True Random Number Generator) usage in BLE pairing/bonding.

For the nRF5340 CPUAPP, we only have the option to get PRNG seeded by TRNG via CryptoCell on-device. 

If you use code in the CPUAPP that requires RNG, then it will be default enabled

mehmetefe said:

Best practices for bonding and key storage when using Zephyr with the nRF5340.

Check out https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-5-bluetooth-le-security-fundamentals/topic/blefund-lesson-5-exercise-2/ 

[mehmetefe]

Hello Amanda,

Thank you for your reply.

We implemented our project based on your suggestions. However, we encountered another problem. Our problem is that when connecting to Bluetooth on iOS devices, the pairing request doesn't appear. On Android devices, the Bluetooth connection is established, and then the Android device sends us a pairing request. When we accept this request, the service opens.

My research revealed that there's no specific solution. Do you have any solutions or resources you can recommend for this issue?

Thank you very much for your time and support.

Best wishes,

Mehmet Efe

[Amanda Hsieh]

Try to erase all or recover the board before programming, and turn off and on BLE on the iOS.