[nRF52833] Link encryption request when connected to an already bonded Host

[Marco R]

Hi,

I'm working on a legacy program (Peripheral) using nRF52833 and nRF5 SDK using SoftDevice S113.

Looking at the Peer Manager module, it seems peer_manager_handler.c is requesting the link to be encrypted immediately on connection (or after a delay, tunable with PM_HANDLER_SEC_DELAY_MS) when connected to a previously-bonded Host (bonding data is present in FDS).

It does so by calling conn_secure() on both:

• Connection establishment events: pm_handler_secure_on_connection() and pm_handler_on_pm_evt()
• Any GATT/ATT error due to insufficient auth level: pm_handler_secure_on_error()

The SDK doesn't seem to have a way to disable this behavior and keep the link unencrypted for as long as the Central desires.

I have a couple of questions below:

1. What's driving the requirement of needing to secure the link upon connection (either immediately or after a delay)? Is it specified in the BT Core Spec? If so, what's the max delay after connection, that can be configured before requiring encryption?
   1. What's the need for requesting encryption unconditionally on connection? My understanding is that if any GATT access requiring higher security is performed, then at that point the security/encryption would be triggered by SoftDevice automatically (for example if Central reads/write Characteristics with level higher than SEC_OPEN)
2. What are the security implications and your recommendation about potentially removing the calls to conn_secure() Connection establishment events (to leave control of when to start encryption to the Central), but keeping it (without any delay) in the ATT auth error handler ? This way if an operation requiring Auth is performed, encryption will still be triggered immediately.

The reason I'm asking is because this behavior interferes with our bonding procedure (which involves some back/forth on non-secured Characteristics with encryption done at the App layer, before triggering BLE bonding/auth).

This only applies to the case where the Peripheral is "Forgotten" in the Central Host's Bluetooth Settings UI, but not on the Peripheral side; so Peripheral thinks the Central is already bonded, while Host does not consider Peripheral a bonded device.

Thanks,
Marco

[Sigurd]

Hi,

The SDK doesn't seem to have a way to disable this behavior and keep the link unencrypted for as long as the Central desires.

I don't see any reason for why you can't simply remove the pm_handler_secure_on_connection() call. If your application later wants to secure the connection, you can call pm_conn_secure(). Or just wait until it's required, by having the pm_handler_secure_on_error() secure the connection if a GATTC procedure fails with insufficient encryption or insufficient authentication.

Marco R said:

The reason I'm asking is because this behavior interferes with our bonding procedure

Maybe you can call pm_conn_secure() when your bonding procedure is completed.

[Marco R]

Thanks Sigurd for confirming that this behavior is only dictated by the application requirements.

I've updated my project include the following changes:

1. Remove the call to pm_handler_on_pm_evt() from pm_evt_handler(), and replace it with pm_handler_pm_evt_log() (so Peer Manager event logging is decoupled from securing the connection).
2. Add a call to pm_handler_secure_on_error() from the main BLE event handler.
   

Thank you,

Marco