OAD Firmware update authentication

We have an option on our OAD to encrypt and authenticate the image. This would prevent an "undesired" device or application from sending an image to your device. More information on this can be found in section 13 of the OAD guide on our wiki page: http://processors.wiki.ti.com/index.php/OAD

Hi Willis1,

Thanks for your quick response.

I have tried to follow the instruction from the Section 13 of the OAD guide. And I've got everything working up until doing the encrypted boot loader. When trying to load an Image-B using SBL Demo Tool it timed out.

I have one doubt from the document:

According to document, to encrypt the Image-B we have compiled EBL with flags, mentioned in document. We have loaded this generated hex file of EBL to CC2541. And then we are trying to load Image-B. Is this correct way?

Please reply ASAP. 

Thanks,

Dhaval

Currently I am stuck with encrypting the image file. I like to get the encryption process going without an extra dev board with specialised firmware. This makes the tool chain maintenance overly complicated. I got it working to the point where I am using BEM + Image A loaded with SmartRF Programming tool, but no success for OAD via bluetooth since I am missing the correct signing sequence (not wanting to use the dev board for this).

So I am experimenting to get it going with a standard tool chain like "openssl". THE OAD documentation on how the encrypted image is constructed is for using the BEM boot loader does not have enough information for doing so.

My experiments so far are not successful:

1) slicing the .bin file in 16-byte header and the rest as payload for encryption via:

openssl enc -e -aes-128-cbc -K your_hex_key -iv your_hex_iv -in payload -out payload-aes-encypted

--> this results in a encrypted binary file which has 16-bytes MAC appended

2) I tried to combine now the unencrypted 16-byte header with the payload-aes-encypted file --> no success

3) I tried to combine the 16-byte unencrypted header like 2) but truncate the resulting image to the original size (e.g. 124k) --> no success

4) I tried to vary the initialisation vector to either all 00 or the one which is used in the BEM "01000000000000000000000000000001" and varied it by 2) or 3) --> no success

5) now I try to reverse engineer the BEM and EBL program :-(

any hints are welcome. I believe by using openssl it would make the image encyption/blessing process more easy to use.  

@ Dhaval V: as far as I understand the encrypted OAD feature prevents the execution of an arbitrary image loaded to an secured device. It does not prevent uploading (e.g. writing to your device flash memory) an image file to your device. So this is potentially harmful for an application (e.g. in my case I store user data in the "other" half of the flash, so any unauthorised writing to flash would destroy the stored data).

Hi WIllis1,

Hope you are doing good!!

Did you get a chance to look at this issue? It is really a blocking issue for us and we are waiting for the possible solution for this from TI.

Once again I am describing the issue for the reference:

1. Flash the BEM (Boot Encryption Manager)

2. Flash Image-A, that is compiled with flags mentioned in the document

3. Flash Image-B on different CC2541 SOC and read it back using SBL demo tool. Here it flashed successfully, but timed out when reading it back using SBL demo tool.

I'll appreciate if you can spare some time for this issue.

Thanks,

Dhaval

Hi Dhaval,

What is it that you are trying to do? Can you explain the purpose of step 3?

Are you planning to send Image B over the air as explained in Section 11 of OAD guide?

Hi Zahid,

Yes we are supporting OAD of the Image-B only.

And to make it authenticated we are trying to follow the Encryption Method supported in CC2541. For that we are following section 13 of OAD Guide. And we are facing difficulties in that as mentioned in my previous posts on this thread.

Let me know if you need any other information.

Please help us to resolve this ASAP.

Thanks,

Dhaval

Hi Dhaval,

Can you please try again with commenting line 71 in oad_target.c:

//  #define BOOTP_E_IMAGE_A

Also in the same file, I've tried a hack to bootstrap image B by hardcoding the CRC-shadow to match:

#if defined (BOOTP_E_IMAGE_A)
#warning "Forcing a CRC-shadow match with the BOOTP_E_IMAGE_A flag - is this bootstrap code?"
  2012,                       // CRC-shadow forced to match CRC for a bootstrap Encrypted Image-A
#else
  2012,//0xFFFF,                     // CRC-shadow must be 0xFFFF for everything else
#endif

Thanks,

Zahid

Hi Zahid,

Thanks for your response!!

But I think there is a confusion here regarding the problem itself. So let me clear it first.

We are using BIM, Image-A and Image-B, where BIM and Image-A, which supports OAD servrice, are resident images and only Image-B upgrades itself every time using OAD feature. Now to make this more secure we want to add encryption and for that we followed the steps from "BLE Developer's Guide for Over-the-Air Download for CC254x" version 1.2, section 13.

1. Steps mentioned in section 13.1, 13.2 and 13.3 is working perfectly. And at the end of that we have BEM and encrypted Image-A in one CC254x and updated version BIN file for Image-B.

2. Now, we have followed 13.4 and generate HEX file for EBL and flash it on the CC254x using SmartRF Flash Programmer with "Erase, Program and Verify" option. And after that we were trying to program Image-B bin file using SBL Demo Tool, after selecting proper Serial Port. It shows "Trying to connect" and then it is Timed Out.

We have also tried to encrypt the Image-B bin file using openssl using following steps:

1. Remove first 16-bytes of header from the BIN file.

2. Encrypt the BIN file using command:

openssl enc -e -aes-128-cbc -K your_hex_key -iv your_hex_iv -in payload -out payload-aes-encypted

Here,

your_hex_key = same as used in BEM

your_hex_iv = same as ivNonce in BEM

3. Now add that 16-byte header to the resulting file to generate the final BIN file and flash it using OAD.

But it is not working. :-(

Please let me know if you need any other details.

Looking forward to have resolution on the same ASAP.

Thanks,

Dhaval

Hi Dhaval,

Which version of Serial Boot Tool are you using? I am using v1.3.1 and I am able to encrypt the image using the default CC2541-OAD-Encrypted-ImgB SimpleBLEPeripheral project. Please verify port settings below:

Hi Zahid,

We had Serial Boot Loader 1.1 and we also tried with v1.2 got from following link:

http://processors.wiki.ti.com/index.php/File:SerialBootTool_1_2_0.zip

But still it is giving time out. Please find attached snapshot of the same.

How can we get Serial Boot Tool v1.3.1? OR Please share the link from where we can download the same.

Thanks,

Dhaval

Hi Dhaval,

Can you verify that you built the EBL with these symbols defined:

SBL_SIGNER

SBL_SECURE=FALSE

Also are you able to load and encrypt the .bin from the SimpleBLEPeripheral that comes with the stack:

CC2541-OAD-Encrypted-ImgB

@Dhaval: I read that you use BIM + Image A as resident image. In case you want to send an encrypted image, only BEM can decrypt it.

@Zahid: any hints on using OpenSSL? Thanks. 

Hi Zahid,

As we are following steps from the Section 13 of "Developer's Guide for Over Air Download for CC254x" and it is mentioned that we need add these two symbols. But I think it should not affect as of now. As currently we are not even able to load the .bin file of Image-B and hence not able read back the encrypted Image-B .bin file.

Also, we have tried with SimpleBLEPeripheral and encounter the same issue.

Thanks,

Dhaval

Hi Kai,

Yes, we know that and that is why we are using BEM and encrypted Image-A.

Thanks,

Dhaval

Hi Dhaval,

Can you please try with the attached BEM hex? It seems to work after flashing the first time on my side. Might need to reflash the BEM each time before loading the .bin.

6813.EBL_CC254x_UART0_ALT1.hex

I have not used OpenSSL but will check if anyone else has.  

Hi Zahid,

Thanks for your reply. 

Even with this EBL, we are getting same error!! But we are now able to achieve similar thing using OpenSSL.

Thanks,

Dhaval

we created bin file using openssl but authentication is failing after OAD process complete , after debugging BEM code we found CRC[0] is not equalling to CRC[1] , can anyone suggest how to resolve this

Replied on your post http://e2e.ti.com/support/wireless_connectivity/f/538/p/1288937/reply.aspx

Dhaval V said:

Hi Zahid,

Thanks for your reply. 

Even with this EBL, we are getting same error!! But we are now able to achieve similar thing using OpenSSL.

Thanks,

Dhaval

Hi Dhaval,

You mentioned you were able to get the OpenSSL method working instead of relying on EBL. How did you do this? I have been able to use EBL to create an encrypted binary and have been using this for testing. I'm using the following method:

1. Create unencrypted binary (eg. unenc.bin)

2. Remove image header (first 16 bytes from unencrypted binary i.e. resultant file should be 16 bytes less = unenc_nohdr.bin). This ensures the image header is not included as data to be encrypted.

3. Encrypt the data using following method in order to create enc_nohdr.bin

openssl enc -aes-128-ctr -K 000102030405060708090A0B0C0D0E0F -iv 01000000000000000000000000000001 -in unenc_nohdr.bin -out enc_nohdr.bin -nopad -nosalt

4. Place back image header (16 bytes that were removed at Step 2) to the start of encrypted file created in Step 3. (eg. enc.bin).

5. Compare resultant file encrypted with openssl (enc.bin) with file encrypted with EBL

The files do not match. Any suggestions? I have not changed the BEM, EBL keys or IV.

Also where does the AES Signature located in the binary? Is this done pre or post encryption? This isn't clear to me.

Cheers,

Jerome

Hi guys,

Any updates on that matter? I'm facing the same problem Dhaval described. I can generate the image but while using Serial Boot Tool to sign it gives a timeout. Where could we download v1.3.1? Is it public available?

Thanks,

Anderson Briglia

I'm once again trying to crack the chestnut of making cc2541 firmware images without using a serial cable etc.

I've written a python script to do it, and I can definately say that the encryption scheme is NOT any of the standard AES algorithms supported by pyCrypt that use an IV:

(*Only* `MODE_CBC`, `MODE_CFB`, `MODE_OFB`, `MODE_OPENPGP`).

Looking through the EBL source code, it's not clear which AES algorithm is used, but at the end of the encryption process

 ENCCS = CBC | AES_ENCRYPT | 0x01;  // Switch to CBC mode for the last block.

Does anyone is Ti know what encryption algorithm is used for cc254x OAD firmware encryption?

Is it possibly not a standard method?

Tim