This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: How to check the link layer is encrypted

Part Number: CC2642R


Dear all
I developed a multi role app working fine, cc2642r can alternate between central and peripheral without problem.
The data exchanged are MIDI over BLE.
I'd like to add encryption to the link layer, as recommended by the BLE MIDI specification.
In order to achieve this, I just modified the services and characteristics declarations, by replacing GATT_PERMIT_READ | GATT_PERMIT_WRITE with GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE.

My original declarations were :

static gattAttribute_t midiProfileAttrTbl[4] =
{
      /////////////////////////
      // 1 MIDI Profile Service
      /////////////////////////
      {
           { ATT_BT_UUID_SIZE, primaryServiceUUID },
           GATT_PERMIT_READ,                        
           0,                                       
           (uint8 *)&midiProfileService           
      },

      /////////////////////////
      // MIDI IO Characteristic
      /////////////////////////

      // 2 Characteristic Declaration
      {
           { ATT_BT_UUID_SIZE, characterUUID },
           GATT_PERMIT_READ,
           0,
           &midiProfileCharMidiIOProps
      },

      // 3 Characteristic Value
      {
            { ATT_UUID_SIZE, midiProfileMidiIOUUID },
            GATT_PERMIT_READ | GATT_PERMIT_WRITE,
            0,
            midiProfileCharMidiIO
      },

      // 4 Characteristic configuration
      {
            { ATT_BT_UUID_SIZE, clientCharCfgUUID },
            GATT_PERMIT_READ | GATT_PERMIT_WRITE,
            0,
            (uint8 *)&midiProfileCharMidiIOConfig
      }
};

I modified the above to encrypt the link layer as follow :

static gattAttribute_t midiProfileAttrTbl[4] =
{
      /////////////////////////
      // 1 MIDI Profile Service
      /////////////////////////
      {
           { ATT_BT_UUID_SIZE, primaryServiceUUID }, 
           GATT_PERMIT_READ,              // Should this declaration be encrypted as well ?
           0,                                        
           (uint8 *)&midiProfileService           
      },

      /////////////////////////
      // MIDI IO Characteristic
      /////////////////////////

      // 2 Characteristic Declaration
      {
           { ATT_BT_UUID_SIZE, characterUUID },
           GATT_PERMIT_ENCRYPT_READ,     // This one was modified
           0,
           &midiProfileCharMidiIOProps
      },

      // 3 Characteristic Value
      {
            { ATT_UUID_SIZE, midiProfileMidiIOUUID },
            GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE,  // This one was modified
            0,
            midiProfileCharMidiIO
      },

      // 4 Characteristic configuration
      {
            { ATT_BT_UUID_SIZE, clientCharCfgUUID },
            GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE,  // This one was modified
            0,
            (uint8 *)&midiProfileCharMidiIOConfig
      }
};

I'm wondering if those changes are enough to enable link layer encryption, or if something else should be updated ?

Also, the service declaration is still GATT_PERMIT_READ, does this declaration should also be updated to GATT_PERMIT_ENCRYPT_READ ?

To finish, I'm using pairing and bonding in this project.

When I use the packetLogger app for MacOs, I can see the messages sent by my device as clear messages, I do not know if the Mac decodes them, but I do not see any encryption here.

Any hint would be appreciated.

Thanks
Jerome

  • Jerome,

    The characteristic encryption hides its values during an unencrypted connection. If you are seeing the values, there is a chance your link is already encrypted.

    As you said, simply adding the option GATT_PERMIT_ENCRYPT_READ to a value and/or declaration is enough to trigger the authentication flag, as shown in the Btool screenshot below.

    CODE

    BTOOL

    You can encrypt the service if you would like to do so. No issues at all. The same flag will be raised as shown above, but for the service itself. 

    Hope this helps,

    Rafael