Kinetis MicrocontrollersのトピックRe: Typo on CRC32 value of Keyblob example?

Typo on CRC32 value of Keyblob example?

javiersoriano — Mon, 12 Dec 2016 16:01:04 GMT

Hello,

I am following the example code from the file: K82P121M150SF5RM.pdf for the Freedom K82f board.

In page 174, there is an example on what the keyblob should look like before and after AES-128 encryption.

I do not see however, an explanation on how the CRC32 checksum is calculated. I have tried using the fsl_crc code, but it gives me different checksum values.

Unlikely but possible: The description says the en address is 0x68ffffff, but the memdump says the value is 0x68fffffb. But I am not sure about this, since the lower part of the end address is supposed to correspond to other flags.

Some questions:

- Must the keyblob always be aes-128 encrypted?

- Is it mandatory to use an encrypted keyblob to use the OTFAD?

- Is there already an AES-128 implementation included somewhere on the SDK?

An extract of my code, basically copied from the crc example on the SDK:

static void InitCrc32(CRC_Type *base, uint32_t seed)
{
crc_config_t config;
config.polynomial = 0x04C11DB7U;
config.seed = seed;
config.reflectIn = true;
config.reflectOut = true;
config.complementChecksum = true;
config.crcBits = kCrcBits32;
config.crcResult = kCrcFinalChecksum;
CRC_Init(base, &config);
}
static uint32_t calc_crc32(uint8_t* data, size_t len)
{
uint32_t checksum32;
CRC_Type *base = CRC0;
InitCrc32(base, 0xFFFFFFFFU);
CRC_WriteData(base, data, len);
checksum32 = CRC_Get32bitResult(base);
return checksum32;
}
crc32 = calc_crc32((uint8_t*)data, 0x20);

Any pointers will be greatly appreciated.

Javier

Re: Typo on CRC32 value of Keyblob example?

Hui_Ma — Wed, 14 Dec 2016 04:30:15 GMT

- Must the keyblob always be aes-128 encrypted?
TS: Yes, the ROM bootloader (QuadSPI) protecting intellectual property with AES-128 algorithm.

- Is it mandatory to use an encrypted keyblob to use the OTFAD?
TS: No.
There are two types of QuadSPI image boot flow:
• Boot from a plaintext QuadSPI image. This method can be used on all targets with QuadSPI support.
• Boot from an encrypted QuadSPI image. This method can only be used on K8x processors that include OTFAD support, such as MK81F256 and MK82F256.

- Is there already an AES-128 implementation included somewhere on the SDK?
TS: Yes, customer could find mmcau module demo for AES-128 algorithm with KSDK V2.0 for FRDM-K82F board:
C:\Freescale\SDK_2.0_FRDM-K82F\boards\frdmk82f\mmcau_examples\mmcau_api

Customer could find more info about Kinetis Bootloader QuadSPI from attached file.

Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Typo on CRC32 value of Keyblob example?

javiersoriano — Wed, 14 Dec 2016 09:48:18 GMT

Hi Hui,

Thanks for the information. I have been reading the QSPI user guide (the one you attached), as well as the "K82 Sub-Family Reference Manual".

- Is it mandatory to use an encrypted keyblob to use the OTFAD?
TS: No.
There are two types of QuadSPI image boot flow:
• Boot from a plaintext QuadSPI image. This method can be used on all targets with QuadSPI support.
• Boot from an encrypted QuadSPI image. This method can only be used on K8x processors that include OTFAD support, such as MK81F256 and MK82F256.

The thing is, I do not want to boot an application from the QSPI. I want to boot from my app from the internal flash, and I want that app to be able to read encrypted data from the QSPI using the OTFAD. Is this possible?

Now, in the following diagram, I see the boot sequence that leads to configuring the OTFAD:

Another question is: Is this the only way to configure the OTFAD? Is there an alternative? For example, instructing my app to write in the OTFAD_CR, OTFAD_CTXn_KEY_Wn, OTFAD_CTXn_CTR_Wn, and OTFAD_CTXn_RGD_Wn registers.

*Note: I will just try it, but I'm posting this for completeness and hoping that someone has walked down this road before.

- What is the criteria to know if the KEK is valid? Is it enough that it is different to all 0's or 1's?

Sorry for all the questions. I am trying to connect all the dots in my mind by asking quesitons here as well, hoping that sometime later this helps another person too.

Thanks in advance.

Javier

Re: Typo on CRC32 value of Keyblob example?

javiersoriano — Wed, 14 Dec 2016 13:19:34 GMT

EDIT: I tried to change the values of the OTFAD control registers from my application (stored in internal flash):

------

#define OTFAD_CR (uint8_t*)0x400DB800

#define OTFAD_SR (uint8_t*)0x400DB804

#define OTFAD_CTX0_KEY_W0 (uint8_t*)0x400DB900

#define OTFAD_CTX0_KEY_W1 (uint8_t*)0x400DB904

#define OTFAD_CTX0_KEY_W2 (uint8_t*)0x400DB908

#define OTFAD_CTX0_KEY_W3 (uint8_t*)0x400DB90C

#define OTFAD_CTX0_CTR_W0 (uint8_t*)0x400DB910

#define OTFAD_CTX0_CTR_W1 (uint8_t*)0x400DB914

#define OTFAD_CTX0_RGD_W0 (uint8_t*)0x400DB918

#define OTFAD_CTX0_RGD_W1 (uint8_t*)0x400DB91C

int qspi_init()

{

uint32_t clockSourceFreq = 0;

qspi_config_t config = {0};

/*Get QSPI default settings and configure the qspi */

QSPI_GetDefaultQspiConfig(&config);

/*Set AHB buffer size for reading data through AHB bus */

config.AHBbufferSize[3] = FLASH_PAGE_SIZE;

clockSourceFreq = CLOCK_GetFreq(QSPI_CLOCK_SOURCE);

QSPI_Init(EXAMPLE_QSPI, &config, clockSourceFreq);

/* According to serial flash feature to configure flash settings */

QSPI_SetFlashConfig(EXAMPLE_QSPI, &single_config);
enable_quad_mode();

}

void otfad_init()

{

uint32_t otfad_cr_value = 0x80300000;

uint8_t test_aes_key[16] = { 0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F};

uint8_t test_ctr[8] = {0x01,0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF};

uint32_t start_addr = 0x68000000;

uint32_t end_addr = 0x68fffffb;

uint32_t otfad_status = 0;
memcpy(OTFAD_CR, (uint8_t*)otfad_cr_value, 4);

memcpy(OTFAD_CTX0_KEY_W0, test_aes_key, 4);

memcpy(OTFAD_CTX0_KEY_W1, test_aes_key + 4, 4);

memcpy(OTFAD_CTX0_KEY_W2, test_aes_key + 8, 4);

memcpy(OTFAD_CTX0_KEY_W3, test_aes_key + 12, 4);

memcpy(OTFAD_CTX0_CTR_W0, test_ctr, 4);

memcpy(OTFAD_CTX0_CTR_W1, test_ctr + 4, 4);

memcpy(OTFAD_CTX0_RGD_W0, (uint8_t*)start_addr, 4);

memcpy(OTFAD_CTX0_RGD_W1, (uint8_t*)end_addr, 4);

memcpy((uint8_t*)otfad_status, OTFAD_SR, 4);

logger_debug("OTFAD status: 0x%x\r\n", otfad_status);

}

but it gives a hard fault from the very first memcpy. If I'm doing it correctly, I am at this point already initializing the QSPI, so I'm unsure on why the hard fault is there, or the reading problems. No luck yet.

Re: Typo on CRC32 value of Keyblob example?

Hui_Ma — Mon, 19 Dec 2016 08:53:24 GMT

Hi Javier,

I am checking with your queries. I will let you know when I collect the whole answers.

Thank you for the patience.

best regards,

Hui

Re: Typo on CRC32 value of Keyblob example?

javiersoriano — Mon, 19 Dec 2016 12:37:29 GMT

Hello Hui,

Much appreciated. I'll continue also doing tests on my side in the meantime.

Javier

Re: Typo on CRC32 value of Keyblob example?

Hui_Ma — Tue, 20 Dec 2016 04:15:20 GMT

Hi Javier,

If QSPI memory could store the encrypted data? The answer is yes.
The QSPI memory doesn't care the stored content is code or data.
Customer does not need to initialize the OTFAD module, the QSPI encrypted data will be automatically decrypted via OTFAD and be placed to AHB RAM Buffer.
As below picture shows that, the related QSPI Flash address is accessible to core or edma module with correct key.

Customer just need to set the keyblob structure with correct start address and end address.
The keyblob structure with up to 4 keyblob entries supported, which customer can use to place ecrypted data to those memory range.
The plain text data also could be placed to QSPI, for example split encrypted data vs. plain text data with different QSPI memory address:

such as:
encrypted data: 0x6800_1000 - 0x6800_5000
plain texted data：0x6800_6000 - 0x6800_F000

Then modify qspi_image_encrypt.bd's end address to the end of your encrypted data with address: 0x6800_6000

the KBOOT will automatically record those start/end address and fill into OTFAD registers to make sure that

0x6800_1000 - 0x6800_5000 will be decrypted while data in 0x6800_6000 - 0x6800_F000 will flow into CPU directly.

NXP provide the Elftosb tool help to create a "secure binary" for SB file to place to QSPI memory range.

Customer could find more detailed info about Elftosb tool with Kinetis bootloader v2.0 software and related document.

The Kinetis bootloader V2.0 software could be downloaded from here.

Wish it helps.

Re: Typo on CRC32 value of Keyblob example?

javiersoriano — Wed, 21 Dec 2016 15:47:06 GMT

I am marking this answer as correct. I had further questions (below) but they are unrelated and/or a topic on its own. If I cannot find the answers for those. I'll open a new discussion. Thanks Hui!