Making and Downloading Security Image for Kinetis Device

Yes

Making and Downloading Security Image for Kinetis Device

Introduction

KINETIS devices have Flash base bootloader or ROM bootloader. They have same structure and same download tools. MCUBOOT shows supported device. The bootloader not only support plaintext image, but also encrypted image which is encrypted by AES. This can protect user’s application code from unauthorized using.

Due to different internal Flash structure, security image making, key download and image download flow is a bit different to each Kinetis devices. This hands-on will introduce Flash base bootloader and ROM base bootloader security image making and downloading.

2 Security image to Flash bootloader

Many NXP Kinetis device SDK have integrated bootloader. Take FRDM-K64F as example, the bootloader project is in

SDK_2.8.0_FRDM-K64F\boards\frdmk64f\bootloader_examples\freedom_bootloader

The bootloader support security format image by default. User can download security format image via UART and USB interface.

In K64 bootloader, the key is stored in 0xb000. But the application code is start from 0xa000. That means each time the application is upgraded, key file need to be download again.

2.1 Generate key

The elftosb tool can generate a key. But of course, you can take any string as key.

2.2 Image encryption

Use the key to encrypt application image. Here is the bd file.

options {

flags = 0x4; // 0x8 encrypted + signed, 0x4 encrypted

buildNumber = 0x1;

productVersion = "1.00.00";

componentVersion = "1.00.00";

keyCount = 1;

}

sources {

inputFile = extern(0);

sbkey = extern(1);

}

section (0) {

erase 0xa000..0xF6000;

load inputFile > 0xa000;

}

2.3 Download key and image

Connect FRDM-K64F openSDA usb port. Then download key and image.

2.4 Download key with KinetisFlashTool

Use keyboard to input key is really annoying. There is a GUI tool named KinetisFlashTool which can download image same as blhost.exe. To download encrypted image by this tool, we can make a sb file to download key first. Here is the bd file.

sources {

}

section (0) {

erase 0xb000..0xc000;

load {{E0BAA2C8231283CAF1D327CEDB82AFF9}} > 0xb000;

}

Using elftosb to generate the sb file. The elftosb command line is as below

\>Elftosb -V -c program_key.bd -o program_key.sb

This sb file should be download at first, then download the encrypted application image. When customer want to download security image via USB MSC or HID, this is the only way to download key. There is a limitation in those bootloader which version is lower or equal to v2.7.0. MSC function and HID function can’t be enabled together. Otherwise bootloader will fail when copy encrypted sb file to MSC disk.

2.5 About the key

But it is really strange that key file should always come with encrypted file. It is reasonable to keep the key in secure status, for example, an untouched place in flash. K64 has a program once field which is located in program flash IFR. This is a standalone space different from main space. It’s address is from 0x3C0 to 0x3FF. MCU core can read or write this area by special flash command. We can put the AES key here. Again, we can use sb file to download this key.

sources {

}

section (0) {

load ifr 0xE0BAA2C8 > 0x3c0;

load ifr 0x231283CA > 0x3c1;

load ifr 0xF1D327CE > 0x3c2;

load ifr 0xDB82AFF9 > 0x3c3;

}

Then we should modify sbloader_init() in sbloader.c. The source code only read key form 0xb000. We should have it read key from IFR.

Security image to ROM bootloader

Some Kinetis device has ROM bootloader. They are different with flash base bootloader. This document use FRDM-K32L2A as example.

3.1 Generate AES key and download the key

The key can be set as 0x112233445566778899aabbccddeeff00. Besides sb file, it can also be programmed to IFR by blhost command.

\>blhost -p COM9 – flash-program-once 0x30 4 11223344 msb

\>blhost -p COM9 – flash-program-once 0x31 4 55667788 msb

\>blhost -p COM9 – flash-program-once 0x32 4 99aabbcc msb

\>blhost -p COM9 – flash-program-once 0x33 4 ddeeff00 msb

If you do not write anything to IFR, the ROM bootloader will use all-zero key. Here I use all-zero key.

3.2 Encryption algorithm

The ROM bootloader hasn’t encryption algorithm. Application should include algorithm code and assign the address to bootloader, or preprogram BCA table and MMCAU code into flash.

You can find MMCAU code (mmcau_cm0p.bin) and BCA(BCA_mmcau_cm0p.bin) table in MCUBoot2.0.0 package.

Before you program these code into flash, new address must be written into it. For example, we put MMCAU code into 0x7f800, then we should modify the BCA table as below