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.

CC2640R2F: Security

Part Number: CC2640R2F


Question 1

Can data stored in CC2640R2F internal flash be extracted by any mean?

 

Reason: Pairing security (keys exchanged between phone and tracker) is stored in SNV of CC2640R2F, we want to know if anybody can extract this from the physical MCU itself. Also if they can extract information from inside the MCU, it means they can reverse engineer our firmware.

 

Question 2

For BLE 4.2, how does the LTK (long term key) computed? From the documentation, it is generated by the ECDH (Elliptic Curve Diffie-Hellman) public key crytography. We would like to know the nature of LTK calculation. Is the seed value for the key random or deterministic? This forum (http://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/586654/2155545?tisearch=e2e-sitesearch&keymatch=cc2640r2f%20encryption#2155545) mentions that it is using TRNG (true random number generator) as a starting point and the rest of calculation done in SW. Does that mean the LTK generated is random?

 

Question 3

BLE 4.2 introduce LE Secured Connection feature. If both the server (peripheral) and client (phone) support BLE 4.2 with LE Secured Connection enable, then it is guarantee that during pairing, server and client will use ECDH to generate and exchange keys. What's happen when the client (phone) does not have LE Secured Connetion enable, do both client and server fall back on legacy way (i.e. using a TK, temporary key, and STK, short term key)?

 

Question 4

We are currently implement OAD off-chip (we have an external flash to store the binary image). We have 2 issues:

1. How do we authenticate that the binary image is really from us and not from someone else? What's a good reliable way to sign that this image is authentic?

2. Since the binary image is stored externally, hacker could extract the image from the external flash ic directly and inject malicious code into it before deliver it as OAD. What kind of approach can we use to mitigate this? Encrypt the OAD image and Decrypt it while coping the image to internal flash (i.e. BEM: boot encrypted manager instead of BIM)

 

Question 5

The Passkey pairing method allows user to enter in 6 digits. Can we have this as alphaumeric and also instead of 6, can we extend it to 8?

 

Question 6

Encounter pairing bug with BLE Stack 3.0.1. Issue is already reported on forum @ http://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/588602?tisearch=e2e-sitesearch&keymatch=cc2640r2%20re-pair.

  • Hello Jason,

    The CC26xx can be configured to inhibit external read/write access from JTAG and/or the embedded ROM Serial Bootloader. These options are described in the CC26xx TRM (SWCU117) "Device Configuration" chapter.

    Regarding Bluetooth 4.2 LE Secure Connections, the TRNG is used during the pairing process to generate a random number where the selected pairing and association method calls for a random number. You can see more details on the pairing process in the Bluetooth specification 4.2, Vol 3, Part H "Security Manager Specification".

    In the BLE stack, you can require Secure Connections pairing by setting the GAPBOND_SECURE_CONNECTION parameter, see gapbondmgr.h:
    #define GAPBOND_SECURE_CONNECTION 0x411 //!< Defines Secure Connections usage. Read/Write. size is uint8. Secure Connections only. @ref GAPBOND_SECURE_CONNECTIONS_DEFINES

    For the secure boot questions, we do not offer this as an example as of now but you could access the ECC APIs and AES crypto driver from the BIM to sign/authenticate your image.

    Lastly, the anomaly in the E2E post has been reported to our test team.

    Best wishes