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.

CC2564: Attribute Permissions

Part Number: CC2564

Hello TI Team,

Out platform uses Bluetopia Stack: Release v1.2 R2 (4.0.1.4)

The Question is how can I set Attribute Permissions (as described in BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] - 3.2.5) to require encryption on read / write access?

Regards

Tobias

  • HI Tobias,

    Let me look into this. Are you looking to encrypt attributes to a GATT profile? (BLE)

    BR,

    Vince

  • Hello Vince,

    yes, the intention is to trigger an encryption from remote device when trying to access a characteristic.

    Regards

    Tobias

  • Hi Tobias,

    I am still investigating this. From what i have found, we support the encrypted GATT services in WL18xx devices, but i don't see any ability to do it CC2564C devices.

    I'll keep digging and let you know.

    BR,

    Vince 

  • Hello Vince,

    How does it work on WL18xx?
    On CC2564 I found following structure definition:

    Possible values for the CharacteristicProperties are:

    But there is no flag for encryption.

    Is this the right place to search?

    Regards,

    Tobias

  • Hello Vince,

    yesterday I installed TI-BT-STACK_LINUX-ADDON for WL18xx.

    Regarding the GATTAPI.h it looks pretty the same. So I suppose it should be possible to use encrypted GATT services on CC256x in the same way?

    Regards,

    Tobias

  • Hi Tobias,

    Yes if it's supported then it should work the same as wl18xx. Have you tried it with any success?

    BR,

    Vince 

  • Hello Vince,

    no, is there any example showing how to use the Attribute Permissions on WL18xx? I couldn't find anything documented...

    You wrote that you support the encrypted GATT services in WL18xx devices, so I suggest there should be anything?

    Regards

    Tobias

  • Hi Tobias,

    Sorry for the delay. From what I have seen so far, the security characteristic is not supported on our device. Can you provide what GATT profile or service you are looking to use?

    BR,

    Vince 

  • Looking more into the 3.2.5 section of the spec, I'm unclear if there is supposed to be a flag that enables this. It looks like security is based on the link, and if that is authenticated and/or encrypted. On our devices, all traffic i believe is encrypted with the link key after connection.

    Is there more documentation you can provide to help understand that?

    BR,

    Vince 

  • Hello Vince,

    What I additionally found is this:

    BR,

    Tobias

  • Hi Tobias,

    I think from speaking to few people now I can confirm if it's not in the SDK, then it is not supported.I am still trying find closure on this issue onto why its not supported, or if there is a way to add it.

    BR,

    Vince 

  • Tobias,

    I got some clarity for Cloud2Gnd, our third party partner who works with the bluetopia stacks - 

    "The way encryption, authentication, and authorization work in GATT (to my understanding) doesn't involve readable flags on attributes, but rather restrictions on what a client can do with a server before it gets an error.


    For example, if you have an attribute representing temperature and you can read it but can't write to unless encrypted, then the client won't know that it requires encryption a priori, but if it tries to write to that attribute on the server, an error response from the server (ATT Protocol level) will indicate that encryption is required. Ditto authentication or authorization, and each have their own dedicated error response. 

     

    Hence, it's the application's responsibility to track which attributes have those flags, and trigger appropriate error responses when a specific access level hasn't (yet) been met. It is then the client's responsibility to bring up encryption, authenticate (bring up encryption using authenication (MITM protection), or authorize (which is implementation-specific).

     

    I'm not aware of any sample code that fully implements this in the default TI SDK build trees, but I don't believe there is any fundamental impediment to adding that behavior to a profile/service. The closest I could find is in PXPDemo for the STM32 build-tree which filters for an INSUFFICIENT_ENCRYPTION error code from the ATT protocol (though it asks the demo user to manually bring up encryption).

     

    In contrast to the comments in the thread, I don't think it matters what controller is used since none of the TI dual mode controllers (as far as I've been able to tell) operate above LL (link layer). In that sense, all ATT and GATT behaviors are host-stack and above, and these behaviors are all application-level."

    It looks like this is not implemented in our examples, but should be possible in application layer. If you need assistance with creating that, i would suggest reaching out to cloud2gnd.

    BR,

    Vince