• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 384 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1310: Collector/Sensor: Disassociate and security list

Hans Christian Glittenberg
Expert 2235 points
Part Number: CC1310

Hi,

When a device is disassociated, it seems that the device is not removed from the security list. Wouldn't this mean that the security list can become full if a device (same physical one) is associated and disassociated many times? Or will the same internal indexes used by the internal security PIB lists just be overwritten? Regardless, what if 50 physical devices associate, then disassociate, and then a 51'th device tries to associate, wouldn't the security list then be full?

Another thing: Since the association request does not have security (I know it can't have this since the device must be in the security list prior to be able to decrypt frames), all the association lists (security etc) can become full of devices that do not have the correct security keys installed (DOS attacks). Shouldn't there be another phase where a device proofs itself to actually having the key, and if not the device should be removed from lists?

  • 0
    TI__Genius 12415 points
    Hei HC,

    To your first question regarding the device not being removed from the sec list, you are correct this is actually a bug, this is currently being fixed and should be corrected in the release at the end of the year since this ticket did not make it to the upcoming release which should be out in the following week I believe.

    To your second question, yes this scenario is possible but we leave device authentication up to the person using the stack. The main reason for this is that we don't want to enforce how people using our stack should authenticate their devices.

    This being said, we are currently evaluating some new security features for 15.4 which might include some sort of device authentication.
  • 0 in reply to Hector_r
    Expert 2235 points

    Thanks for clarification.

    Meanwhile, I would like to know which PIB attributes that are written to by using ApiMac_secAddDevice. I guess it is only these two: ApiMac_securityAttribute_keyDeviceEntry and ApiMac_securityAttribute_deviceEntry. Then I can write my own secRemoveDevice.

  • 0 in reply to Hans Christian Glittenberg
    TI__Genius 12415 points
    to remove a device from the security list you can use the API "ApiMac_secDeleteDevice"
  • 0 in reply to Hector_r
    Expert 2235 points
    Ahh, forgot that one.. But if I would like to inactivate/delete a specific key (among many) associated with a specific device, I can use ApiMac_securityAttribute_keyDeviceEntry I assume.
  • 0 in reply to Hans Christian Glittenberg
    TI__Genius 12415 points

    If you just want to invalidate/remove a key from a device, you would have to look for that device/key in ApiMac_securityAttribute_keyDeviceEntry

    once you find the entry for that specific device index and key index you have to set the deviceDescriptorHandle to 0xffff as shown in the code below.



    keyDeviceEntry.deviceEntry.deviceDescriptorHandle = 0xffff;
ApiMac_mlmeSetSecurityReqStruct(ApiMac_securityAttribute_keyDeviceEntry, &keyDeviceEntry);