CC2642R: Bond Manager - GAPBOND_SECURE_CONNECTION_ONLY

Joshua Meyer

Part Number: CC2642R

Hello,

I'm working on making sure all of the security requirements are met for a BLE product and have a few questions. We'll be running the latest BT 5 stack on a CC2642 when we go to production in our peripheral device, and the central will be running at least BT 4.2. Neither device has input or display capability, so we won't be able to enable MITM protection, i.e. we have to use the "Just Works" pairing association.

We want to use the highest level of security possible given our constraints. With this in mind I have the bond manager configured as follows on our peripheral:

void appBleInitBondMgr(void)
{
    // No I/O capability in central or peripheral
    uint8_t mitm = FALSE;
    uint8_t ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
    uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
    uint8_t bonding = TRUE;
    uint8_t bondFailAction = GAPBOND_FAIL_TERMINATE_LINK;
    uint8_t secureConn = GAPBOND_SECURE_CONNECTION_ONLY;

    GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairMode);
    GAPBondMgr_SetParameter(GAPBOND_MITM_PROTECTION, sizeof(uint8_t), &mitm);
    GAPBondMgr_SetParameter(GAPBOND_IO_CAPABILITIES, sizeof(uint8_t), &ioCap);
    GAPBondMgr_SetParameter(GAPBOND_BOND_FAIL_ACTION, sizeof(uint8_t), &bondFailAction);
    GAPBondMgr_SetParameter(GAPBOND_BONDING_ENABLED, sizeof(uint8_t), &bonding);
    GAPBondMgr_SetParameter(GAPBOND_SECURE_CONNECTION, sizeof(uint8_t), &secureConn);

}

Now for a few questions:

What exactly does setting the GAPBOND_SECURE_CONNECTION parameter to GAPBOND_SECURE_CONNECTION_ONLY do? My interpretation of sections 10.2.4 and 10.3 (Vol 3, Part C) of the Bluetooth specification is that "Secure Connections Only" is only possible when pairing is performed via LE Secure Connections and MITM protection is also used. Is "GAPBOND_SECURE_CONNECTION_ONLY" a valid configuration when MITM protection isn't supported? The only difference I've noticed between GAPBOND_SECURE_CONNECTION_ONLY and GAPBOND_SECURE_CONNECTION_ALLOW is that the bond manager rejects pairing requests from centrals that only support the LE Legacy Pairing procedure when the setting is GAPBOND_SECURE_CONNECTION_ONLY. This is desirable, as we want to avoid key generation via Legacy Pairing, I just want to make sure this configuration is acceptable.
Does the "GAPBOND_BOND_FAIL_ACTION" do anything on a perihperal? Looking at the bond manager code, it appears this setting only applies to centrals...
As far as securing our applications custom GATT service goes, I'm thinking I need elevate the permission levels on our characteristic value attributes to "GATT_PERMIT_ENCRYPT_READ and/or GATT_PERMIT_ENCRYPT_WRITE", and require a 16-byte encryption key size when registering the service via GATTServApp_RegisterService(). Is this configuration correct for locking down the characteristics so they can only be read/written when the link is encrypted with a key generated via the LE secure connections procedure?

Thanks

Josh

over 7 years ago

0 Christin Lee over 7 years ago

TI__Guru 56875 points

Hi,

Answer 1 : Secure connection is using a different method during pairing and it will still work with Just Work. You can find the detail in our software user's guide :
dev.ti.com/.../gapbondmngr.html

Answer 2 : The GAPBOND_BOND_FAIL_ACTION is set when master receiver LL_REJECT_IND with error code PIN or key Missing. The re-initiate encryption can only be started from master, and a master can decide what to do if slave is missing enc keys. if the master is missing keys to start with, then it would not re-initiate encryption.

Answer 3 : The encryption is done in the SM manager. You don't need to do anything on the application layer.

0 Joshua Meyer over 7 years ago in reply to Christin Lee

Expert 1080 points

Hello Christin, thanks for getting back to me. A few more comments / follow up questions:

1). I understand that the GAPBOND_SECURE_CONNECTION secure connections parameter effects which key generation method the bond manager tries to use. However, the part I'm still unsure of is the Bluetooth 5 specification defines "Secure Connections Only Mode" in Vol 3, Part C, Section 10.2.4. The TI bond manager has the GAPBOND_SECURE_CONNECTION_ONLY option for the parameter, but from what I can tell, this doesn't map directly to "Secure Connection Only Mode" as defined by Bluetooth.

3). Yes, the SM handles encrypting the traffic, but only when encryption is enabled. In our application we do not want to allow any access to our BLE service on unencrypted links. At what level in our GATT profile definition do I need to apply the "GATT_PERMIT_ENCRYPT_WRITE / GATT_PERMIT_ENCRYPT_READ" permissions? My best guess is if I set all characteristic Value and CCC attributes to require encrypted permissions this should handle it?

Thanks,
Josh

0 Christin Lee over 7 years ago in reply to Joshua Meyer

TI__Guru 56875 points

Answer 1 : It does work as define from the specification. Once it's set, device can only be pairing/bonding with secure connection.

You can find the following paragraph in gapbondmgr.c

#if defined(BLE_V42_FEATURES) && (BLE_V42_FEATURES & SECURE_CONNS_CFG)
          // Section 2.3.5.1: "If the key generation method does not result in a key
          // that provides sufficient security properties then the device shall send the
          // Pairing Failed command with the error code "Authentication Requirements.""
          // This supports Secure Connections Only Mode, where if the remote device does
          // not support Secure Connections and the local device requires Secure
          // Connections, then pairing can be aborted here with a Pairing Failed command
          // with error code "Authentication requirements".
          if ( gapBond_secureConnection == GAPBOND_SECURE_CONNECTION_ONLY )
          {
            if ( !(pPkt->pairReq.authReq & SM_AUTH_STATE_SECURECONNECTION) )
            {
              // We are not interested in pairing with this device.
              VOID GAP_TerminateAuth( pPkt->connectionHandle, SMP_PAIRING_FAILED_AUTH_REQ );

              break;
            }
          }

Answer 3 : Yes, just set characteristic value and ccc attribute to require encryption permission.

0 Joshua Meyer over 7 years ago in reply to Christin Lee

Expert 1080 points

Thanks for getting back to me Christin.

Now that we've gotten the firmware on our central updated to work with GATT permissions that require encryption I was able to do some experimenting with the GAPBOND_SECURE_CONNECTION parameter and confirm that it does work as described in the specification.

If I set the permissions on an attribute to GATT_PERMIT_ENCRYPT_READ, and have GAPBOND_SECURE_CONNECTION_ONLY enabled, the stack responds with an "Insufficient Authorization" error when the central tries to read the attribute (since the pairing is performed without authentication). Once I switch to GAPBOND_SECURE_CONNECTION_ALLOW, the characteristic's can be read, assuming the link is encrypted.

Bluetooth®︎

Bluetooth forum

CC2642R: Bond Manager - GAPBOND_SECURE_CONNECTION_ONLY