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.