• Locked Locked
  • Replies 16 replies
  • Subscribers 57 subscribers
  • Views 3191 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

encrypted OAD - handling issues and security risks

Thomas Treyer
Prodigy 240 points
Other Parts Discussed in Thread: CC2541

OAD is a nice feature, many thanks to the TI guys for providing some sample code for this. Nevertheless I am not happy with the TI solution for OAD for 2 reasons:

1. Encrypting the bin files with the help of an evaluation board (which we do not have) and serial cables (our Macs have no serial ports) is a mess and does not allow to integrate the encryption into the SW production process automatically.

2. The encryption method chosen by TI seems to be vulnerable.

To solve the first problem we developed a tool to encrypt the .bin files and integrated this tool into the Xcode development process of our iPhone app. Whenever we create a new FW version with IAR, the build process will automatically encrypt the .bin files and will copy them into the iPhone app, which is the OAD master.

For this development we needed to do heavy reverse-engineering of the BEM sample code and the EBL sample code. During reverse engineering we found that it seems to be very simple to decrypt an encrypted .bin file even without knowing the key and iv. We did not test this security attack because we have no test file available, which has been encrypted with the TI sample code EBL.

We changed the encryption method in the following way.

1. We sign the bin file with AES128-CBC-MAC. During signing we skip the 16 Byte block where the signature will be stored.

2. For signing we use no salt, nonce or iv.

3. For signing we use a key which is distinct from the key used for encryption. This signature key is a shared secret between the Xcode development site and the CC2541 module.

4. We encrypt the complete file excluding the img header (First 16 bytes).

5. The signature is the first block to be encrypted and is different from ImgA, ImgB and different from version to version.

6. We encrypt using AES128-CBC. We encrypt the bin file as a whole. The key and the iv is a shared secret between the Xcode development site and the CC2541 module. The key and iv is always the same for the lifetime of the product.

7. We strip the padding, which is appended to the bin file by the standard encryption tools and rely on the fixed length of ImgA and ImgB.

My question to the reader is: Is there a security risk visible in this encryption strategy?

My advice for the reader is: Do not use the encryption strategy of the TI sample code. Change it!

  • Intellectual 390 points

    After getting OAD with BIM working, I am looking into making BEM work with the AES encryption. So far I got BEM with ImgA running. Now I am getting to the stage to use OAD upload with AES encrypted binary file. Here I am stucked not getting the boot image enabled by BEM... here is the process I am using for creating the encrypted files:

    1. in oad_target.c I commented the
    //#define BOOTP_E_IMAGE_A

    2. made sure that FEATURE_OAD_SECURE and FEATURE_OAD_BIM are defined in the preprocessor options. Also Linker and Post Build settings updated to the "secure" version.

    3. Compile All for each ImgA and ImgB, no errors, no warnings

    4. take ImgA.bin and ImgB.bin file to signing procedure:

     - split first 16 bytes (header) from each file

    - run "openssl enc -aes-128-cbc -k 0102030405060708090a0b0c0d0e0f10 -in input.bin -out output.bin

     - put unencrypted header in front of the encrypted output.bin and truncated the file to the original file size to (e.g. 124k)

    5. try to upload the file via OAD (e.g. iOS multitool) 

    --> doesn't work. :-( 

    I made sure that both keys are the same in BEM and my openssl signing key. I don't have any TI dev board for doing the signing procedure. Does anyone use successfully openssl for signing?

  • in reply to Kai Scheffer
    Prodigy 70 points

    Did you try using aes-128-cbc instead of 256?

  • in reply to Kranti Kambhampati
    Intellectual 390 points
    Yes, this was an error in my post. I corrected the original post. aes-128-cbc didn't work :-( Have you been able to to encrypt an image? In case you have an original and encrypted version of an image available, would you be able to share this with me, so I can run my commands and see where it fails? TX Kai
  • in reply to Kai Scheffer
    Prodigy 70 points

    Add -nopad to openssl

  • Prodigy 210 points

    Hi Thomas ,

    1. Why do you think the BEM and EBL are vulnerable? what is the vulnerability you see there? 

    2. In your new method, I think using the same IV to encrypt every time is problematic. I think it is usually passed with the message.

  • in reply to nir eng
    Prodigy 240 points

    Hi nir eng,

    Regarding the vulnerability I do not want to give more explanation to protect the projects based upon the sample code. My recommendation for new projects is to make it different than it had been done in the sample code. I cannot tell you what exactly the difference should be without compromising existing projects. 

    The problem is that any OAD update cannot change the decryption routines, because the BEM cannot be updated in the field. If an exploit would exist it would not be possible to solve the problems by a simple update. You would need to replace all the hardware in the field.

    Regarding the same IV I hoped that the structure of the data helps a little bit because the first bytes of the data are different always, acting somehow as an additional salt. What do you think?

  • in reply to Thomas Treyer
    Prodigy 210 points

    can you send me the info about the vulnerability to nire5555@gmail.com?

    I was also thinking to use some of the function from the sample code for my main app (like aesCrypt and aesSignature), so it is even more important for me to know the security risks.

    regarding the same IV, you may be right  but I am not a security expert. There are  threads like

    http://stackoverflow.com/questions/3008139/why-is-using-a-non-random-iv-with-cbc-mode-a-vulnerability 

    which explains the problems with that. I guess you need to understand if any of the possible attacks apply to your use case.

  • in reply to nir eng
    Intellectual 685 points

    can i have encrypted bin file which is created by using openssl ..... 

    we are tried using openssl method but authentication is failing .... can anyone have solution for this ?

  • Expert 1360 points

    I'd like to know more about why the encryption method chosen by Ti is insecure.

    I can supply you with a FW image that I have encrypted using the SBL method to test the proposition.

    tim-at-adaptics.co

    I believe that locking flash page 0 that contains the encryption keys is vital? 

  • in reply to Kadari Rajamallaiah
    Genius 4470 points

    Please remove first 16-bytes header from the .bin file before encryption and then put it back at the beginning of the encrypted file.

    Hope this helps!!

  • in reply to Tim Redfern
    Intellectual 685 points

    Dear Tim ,

    can you share the FW image which you encrypted .. we need that for testing 

  • in reply to Kadari Rajamallaiah
    Expert 1360 points

    Hi Kadari,

    Here is a FW image that I have encrypted.

    Let me know if you can crack it!

    Tim

    dropFW_260814_encB.bin.zip
  • in reply to Tim Redfern
    Intellectual 685 points

    Dear Tim ,

    I tried with your bin file but the same problem is repeated . I able to upload bin file successfully but crc[0] is not equalling to crc[1] value . can you send complete hex and bin files 

    so that we can check clearly

  • in reply to Kadari Rajamallaiah
    Expert 1360 points

    I think we are talking at cross purposes.

    I haven't found that the openssl method works.

    I'm interested that there may be a way to circumvent Ti's encryption method.

    The .bin file I sent was encrypted using Ti's method. Don't think you will be able to use it without my encryption keys.

  • in reply to Tim Redfern
    Intellectual 685 points

    Thank you Tim ,

    we need bin file which is created by using openssl method .

  • in reply to Dhaval V
    Intellectual 685 points

    Dhaval ,

    we tried in that way ( removed first 16bytes header from the bin file before and added later to encrypted file ) but we didn't succeed . We are able to do OAD with encrypted bin file we are getting message " FW Image Upgraded successfully " ( we are using SensorTag app) but Image type is not changing .

    After debugging the code we found that crc[0] is not equalling to crc[1] value .

     

    can you suggest what else we need to do get success ?????