• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 833 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.

CC2640 BLE-STACK 2.0.0 Testing / Security Validation

Robb S
Expert 3120 points

Other Parts Discussed in Thread: CC2640, BLE-STACK

Is there any information on the following for the CC2640:

What security testing/validation does TI do on the BLE-STACK 2.0.0 for the cc2640?  

Is there any 3rd party auditor reports available on this BT stack?

 

Thanks,

Robb

  • 0
    TI__Guru** 105180 points

    Hi Robb,

    Can you clarify the context of "security testing/validation"? The BLE Stack is BT certified by testing but we don't have any 3rd party analysis reports on the SW.

    Best wishes

  • 0 in reply to JXS
    TI__Expert 3120 points

    The question on "security testing / validation" is to cover auditing of 3rd party SW for good coding pratices.  Also, what is exactly performed and by whom to say that the solution in BLE Stack certified BT4.1? Is this in conjunction to the Bluetooth SIG?

    Thanks,

    Robb

  • 0 in reply to Robb S
    Intellectual 495 points
    The stack is certified by the Bluetooth SIG for compatibility and interoperability according to a set of test promulgated by the BT SIG. These test check for operation, they don't dwelve into the implementation itself. If you're asking about whether TI's Stack and code has been through Lint and is built according to specs, I don't know if they would share (and no vendor really shares it). This could be important in applications where reliability is important. But in the products we've worked on that have to meet safety protocols, the key is that the system should operate correctly even if the BLE stack fails.

    Are you asking about the security as far as exploitation (buffer overflow, etc) or protection of wireless data?
    It's important to note that Bluetooth v4.0 and v4.1 are mostly insecure because the keys used for encryption are derived by using 0 or a 6 number PIN. Only the Out of Band method is actually safe since you transmit the 128-bit key over another mechanism (that could be very safe or very insecure). But this method is inconvenient and not very common.
    Companies like mine have built custom solutions on top of the Bluetooth Stack to enhance security. For this to work, both App and Device need to have the protocols.

    Bluetooth v4.2 adds much of the secure key exchange of the Classic Bluetooth which makes things a lot better, but support for v4.2 is still not broadly available because some features require hardware changes.