KBOOT: location of BL_FEATURE_ENCRYPTION_KEY_ADDRESS

[peterruesch]

Hi,

I'm having trouble getting wise from the documents supplied with the KBOOT Bootloader.

My current question is: where is the (AES128) key stored the bootloader uses to decrypt possibly encrypted firmware ("secure binary") it receives?

from various examples I see, there is a symbol called BL_FEATURE_ENCRYPTION_KEY_ADDRESS which is defined as "0xb000"

from the other symbols I see, that the default application offset is 0xa000. this would imply that the key is stored in the address space of the application.

In my understanding the bootloader should have some sort of key store in the address space before the application.

can you light me up?

best regards

[peterruesch]

Thanks David for the upload. I will have a look into it. Is there a upstream repository where such changes are tracked and collected?

Jie, you propose that the key should not be stored in the bootloader address space. Whats your suggestion then?

[jay_heng]

there are two ways to store the AES128 key:

if BL_FEATURE_ENCRYPTION_KEY_ADDRESS is defined, that means user wants to store the key in somewhere of flash memory area, the key address can be set arbitrarily (Note: the address shouldn't be located in bootloader area).

if BL_FEATURE_ENCRYPTION_KEY_ADDRESS is not defined, that means user should use the default key address, the address is located in dedicated flash IFR area (0x30 - 0x33), this area can only be accessed by special bootloader commands (flash-read-once, flash-program-once), and it is write-once.

[DavidS]

Hi Peter,

I ran into this issue a month or so ago and have only made my personal notes (README_DES.txt) and comments in the source "C" code (look for "//DES").

ZIP file attached.

In summary I figured out how to create a simple ascii key text file that has the 128-bit AES custom key.

Ex: decafbadface0fffc0ffee00deadbeef

The command line elf2sb.exe is used to convert binary or elf file using the key file to get a *.sb (secure boot) file.

Example command lines in README_DES.txt.

The sbloader.c file is in the ZIP too that has been modified to have the same custom key and looks like:

uint32_t s_aesKey[AES_128_KEY_SIZE_WORDS]={0xdecafbad, 0xface0fff, 0xc0ffee00, 0xdeadbeef}; //DES works for key file "decafbadface0fffc0ffee00deadbeef"

Notes:  This was done using Kinetis_Bootloader_2_0_0 for the USB MSD secure boot drag-n-drop of the Secure Binary (*.sb) file.

Hope this helps.

Regards,

David

[peterruesch]

I edited the command file to include the supplied binary into the sb file.

It also warns you if you dont provide and offset address which is mandatory for binary input files.

here is an output log form the bd file:

[developer@localhost debug]$./elftosb -V -f kinetis -z -c command_file.bd -o led_demo_bin_zero_key.sb -DAPPLICATION_OFFSET=0xA000 $PWD/gpio_led_output_frdmk64f.bin 
APPLICATION_OFFSET = 40960
APPLICATION_BINARY = /opt/Freescale/sdk_2.0/boards/frdmk64f/driver_examples/gpio/led_output/kds/debug/gpio_led_output_frdmk64f.bin
Boot Section 0x00000000:
  ERAS | adr=0x00000000 | cnt=0x00000000 | flg=0x0001
  LOAD | adr=0x0000a000 | len=0x00004de8 | crc=0xb2e27f35 | flg=0x0000
  RESET
[developer@localhost debug]$ ls -lh led_demo_bin_zero_key.sb 
-rw-rw-r--. 1 developer developer 20K Jul 11 10:35 led_demo_bin_zero_key.sb

[DavidS]

Hi Peter,

Back from a day off.

Looks like you are well on your way.  Good work and thanks for sharing your command file.

Have you implemented using the customer key successfully?

Regards,

David

[peterruesch]

Hi David,

thanks for stopping by.

No, I have not yet put more effort into a custom key solution. As you can see from my community activity, there are more open questions.

I want to change the source code as little as possible to keep it "mainline". And at some points I am not sure which is the most compatible solution.

I'm very happy you share my thoughts! Do you have an idea how this matter (location of aes key) is treated in the future?

Jie Heng proposes to store the key not in the bootloader area. can you tell me why?

https://community.nxp.com/thread/429945#comment-810357

[DavidS]

Hi Peter,

Jie is indicating two separate locations that a "key" could be stored in the MCU.  One being the Flash just like any other variable gets stored.  The other is the IFR (nonvolatile information register) field which is "hidden" from normal Flash space and accessed using special flash command sequence.  That IFR has OTP (one time programmable) fields so if that is OK you could use it.

The real issue is how secure do you want the key.  If the Flash is "locked" (using the flash configuration field FOPT/FSEC fields) the normal Flash can be protected.

Other Kinetis devices have a DryIce module for storing keys.  I  suspect with time (and IoT devices evolving )more and more methods for securing keys will be implemented in silicon.

Hope that helps.

Regards,

David

[peterruesch]

I have the following line from the README_DES.txt:

Generate *.sb file with key file from binary input file:
elftosb.exe -V -f kinetis -k ledkey.txt -c led_demo_bin.bd -o led_demo_bin+key.sb led_demo.bin

where does the offset of 0xA000 come from shown in the output of this command?

[developer@localhost debug]$ ./elftosb -V -f kinetis -z -c led_demo_bin.bd -o led_demo_bin_z_key.sb gpio_led_output_frdmk64f.bin 
Boot Section 0x00000000:
  ERAS | adr=0x0000a000 
| cnt=0x00002800 | flg=0x0000

you did not specify it in the *.bd file. I thought this is something mandatory.

br

[peterruesch]

ahh.. it's coming from the erase command. 40k == 0xA00.

but why did you comment out all other lines in the bd files? the resulting secure binary does not contain the application!