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.

Security Framework for IoT Enabled BLE Device

Part Number: msp432, cc2640r2


Hello everyone,

Sorry if this thread is not much correlate with specific BLE problem. Please pardon me and let me know if there is a room for this type of discussion.

My company is developing a product using TI MSP432 with CC2640R2 as Simple Network Processor. We chose this platform because we would like to add Apple Homekit for our future updates and we are exciting with the prospect of BLE 5 which has been supported by CC2640R2. This product will be released as first IoT product for our company.

What we concern are how to manage a BLE products lifecycles. Beside secure communication when device is operating, we get lost that we also needs to design the device life such as:

  • How we manage the product activation when user bought and operate it at first time?
  • What should happen at first? Should smartphone check to cloud for firmware updates?
  • How to manage firmware updates? Especially what if the cloud application changes but devices on stores still the old production batch and should be updated first?

So my questions are:

  1. Does anybody has advice on where to look for whitepapers/references that describes these whole thing?
  2. Does anybody know how companies manage their IoT product lifecycle including the security?

Thank you and have a nice day

  • Hello,
    What you are asking is a common challenge within the IoT market. From a security point of view, you should make use of device management services on the cloud side, to manage firmware upgrades that can propagate through the smartphones to the end product. This should be part of the product activation as you say, especially since you don't know how long the product is going to spend "on-the-shelf". You should also consider a business model with the approach of as-a-service or put an expiration date, to make sure customers don't get to experience left out upgrades.

    This thread could go on endlessly as your enquiry is quite wide. There are multiple good articles out there, here are two high level ones I like (From HBR)

    hbr.org/.../how-smart-connected-products-are-transforming-competition
    hbr.org/.../how-smart-connected-products-are-transforming-companies

    When you are ready for more discrete, technical and detailed questions. Specifically on our platforms, hit E2E again.
  • You will find TI guidelines here: 

     

    This is also a good read on security:
    www.ti.com/.../swpb020a.pdf

    Are there any more technically or specific questions?

  • Hi Joakim

    Sorry for late reply. From the reference that you gave, especially my concern about identifying and authenticating the device on network, it is said that we can use the Unique ID and optionally a signature/certificate key whose public key can be shared easily on cloud. I want to know more about this, from what I saw on popular platform such as AWS and Azure, issue a certificate seems the standard way in doing this (use provided CA), the certificate could contain the UID as part of it that is associated with public key. In case of BLE product which has no direct connection to cloud, then smartphone shall be the gateway in relaying the certificate to be authenticated on cloud (end-to-end device authentication). Then my questions are:

    1. If using the UID directly, is it dangerous since anyone who can read the UID can somehow impersonate the device?
    2. Because it is said that certificate key is optionally, do you think there is a simple yet secure device authentication to cloud just by utilizing UID? Should it also incorporate some sort of cryptographic process?

    Thank you Joakim

  • Hi,
    Your questions are very relevant for IoT deployment of BLE devices, although somewhat a bit hard to answer. There are currently no standards on how to handle the certificates through a BLE setup. The certificate is stored locally in the embedded device (supposedly not hardcoded to Flash/RAM) and it's crucial to not only protect the information in storage but in transit as well. BLE provide a solid security containment once the pairing/bonding is done, which is where certificate information could exchanged. That being said, without actually answering your questions (sorry), I think these high level discussions might be more suitable elsewhere. For technical support and specific considerations, feel free to open a new thread.

    By the way, everything can be hacked given enough time and resources. Just make sure to make it hard enough so it's not worth it :)

    Best Regards
  • Hi,

    Thank you Joakim for your support and advice. I think I will do more research on web and papers

    Kind regards,