Some issues about CSEc module

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Some issues about CSEc module

Jump to solution
1,609 Views
Keane
Contributor I

I am working on S32K146 with S32DS 3.4, but encountered some problems while using CSEc module.

About CSEc module, in my understanding it consists of 2 parts:
a) to provide functions of encryption and decryption by keys.
b) to provide functions of CMAC and verify it(secure boot).

My problem is aboot the usage of CMAC.
I'm going to realize a function that is used to verify some data after ECU every time boots.
The start address of the data is unfixed. Maybe it starts from H’0x2000 or H’0x4000 and so on.

Since I have debugged CSEc module, I had these issues:
a) Is “CSEc_RAM_KEY” the only key to calculate MAC when dataPtr(start address of target data segment) doesn’t start from H'0x0?
I tried to use ohter keys (inculding CSEC_BOOT_MAC_KEY/CSEC_KEY_1/CSEC_KEY_2 ) to calculate MAC, but only got the reply “CSEC_ERC_KEY_INVALID”.
b) What are the differences between function ”Csec_GenerateMacAddrMode” and function “Csec_GenerateMac”? They both have the same “brief”, “details”, “param” but I can't use function ”Csec_GenerateMacAddrMode” to calculate MAC with “CSEc_RAM_KEY”. Through function “Csec_GenerateMac”, it can work.
c) Where can I store the MAC? It needs to meet the requirement of cyber security, which means that the storage place should be protected by CSEc module. Which functions can I use to store it? And it can't be initialized after ECU boots, either.
d) Similar to the questions above, I want to know the meaning of 'CSEC_BOOT_MAC'. Is it only used with 'CSEC_BOOT_MAC_KEY' to save MAC when dataPtr begins with H'0x0 (header of BOOT)?

I will appreciate it if someone can help me to solve those problems.
Best regards.

0 Kudos
1 Solution
1,457 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

if it works when stepping the code, it's caused by read-while-write error, most likely.

lukaszadrapa_0-1665990579196.png

You can try to disable interrupts when generating the MAC.

Regards

Lukas

View solution in original post

0 Kudos
10 Replies
1,593 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

a) RAM_KEY and user KEYs can be used for MAC calculation but KEY_USAGE attribute of such key must be set.

See please page 8 in:

https://www.nxp.com/webapp/Download?colCode=AN5401&location=null

https://www.nxp.com/webapp/Download?colCode=AN5401SW&location=null

b) Csec_GenerateMacAddrMode uses pointer method, so it’s faster than Csec_GenerateMac. When using Csec_GenerateMac, it’s necessary to copy all the data to CSEc engine manually (this is done by the function). Next important difference is that Csec_GenerateMacAddrMode works only for Program Flash. If you need to calculate MAC over data in Data Flash or in RAM, it’s necessary to use Csec_GenerateMac.

 c) Only BOOT_MAC for secure boot is stored in CSEc secured flash. If you have some own MAC, it must be stored to normal flash. If it is constant, it can be covered by secure boot feature.

 d) Please read “4.4 Secure Boot” in AN5401. Yes, secure boot calculates MAC over data in Program Flash always starting from 0x0 (this cannot be changed) up to size defined by user. This is done automatically during/after reset. Section “4.4.1 Secure Boot Modes” explains what will happen if it fails.

Regards,

Lukas

0 Kudos
1,587 Views
Keane
Contributor I

Hi Lukas,

Thanks for your reply. It helps me a lot. Now I can calculate my own MAC and store it in normal FLASH.

But now I have some issues with MAC verification.

There are 2 functions related to MAC verification, but I can't distinguish function "Csec_VerifyMacAddrMode" and function "Csec_VerifyMac".

I'm using function "Csec_GenerateMac" to calculate MAC. Should I choose function "Csec_VerifyMac" to verify MAC, too?  Should they be used in pair? Just like function "Csec_GenerateMac" and function "Csec_VerifyMac", function "Csec_GenerateMacAddrMode" and function "Csec_VerifyMacAddrMode".

I have some idea about the issue. Is it affected by " little-endian"? Firstly I used data segment filled by full 0x0, and it can verify MAC successful. Next I replaced the filled data with random data, but it failed.

Regards,

Keane

0 Kudos
1,570 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

The best way is to use "Csec_GenerateMacAddrMode" together with "Csec_VerifyMacAddrMode" when generating/checking a MAC on Program Flash. Those won’t work on Data Flash or on RAM. Due to nature of these commands, you will achieve better performance because “non-AddrMode” functions will be slower due to software overhead.

And similarly, use "Csec_GenerateMac" and "Csec_VerifyMac" when your data are in Data Flash or in RAM.

So yes, use them in a pair.

 

There could be a problem with endianness. SHE specification provides test vectors which can be used for comparison of the results

For CMAC, the values are:

KEY      2b7e151628aed2a6abf7158809cf4f3c

MESSAGE    6bc1bee22e409f96e93d7e117393172a

OUTPUT    070a16b46b4d4144f79bdd9dd04a287c

 

AN5401SW expects that the numbers are provided in this form:

uint32_t key[4] = {0x2b7e1516, 0x28aed2a6, 0xabf71588, 0x09cf4f3c};

uint32_t data[4] = {0x6bc1bee2, 0x2e409f96, 0xe93d7e11, 0x7393172a};

 

And SDK driver expect this format:

uint8_t key[16] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c};

uint8_t data[16] = {0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a};

 

The data are then stored in different order in the memory.

 

AN5401SW then works with the data as with 32bit words, SDK driver works with the data as with 8bit words, so the input data are swapped by the driver and the result is then also swapped.

 

Regards,

Lukas

0 Kudos
1,548 Views
Keane
Contributor I

Hi Lukas

I want to add something to yesterday's e-mail since I have new progress today.
 
I used "Csec_GenerateMac" and “Csec_VerifyMac” to calculate MAC and verified the value through using header address of application as parameter just now, but I found that the data length can’t be longer than 112 bytes.

Summary:
CASE A : Read data to buffer first
the longest length of the target data may be 0x3B0(vague data).

CASE B : Header address of application as parameter
the longest length of the target data is 112 bytes.

Is that circumstance normal? How am I supposed to do to expand the length of the target data?
 
Best Regards,
Keane
0 Kudos
1,520 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,
not sure if I can understand.
There's no limitation for length in case of Generate MAC command. Notice that the length is a number of bits, not bytes.
Generate MAC command can be used for any location - program flash, data flash, RAM. In case of pointer method, only program flash can be used.
Regards,
Lukas

0 Kudos
1,505 Views
Keane
Contributor I

Hi Lukas

I want to add something to yesterday's e-mail since I have new progress today. 

Will the simulation debug type affect the running of the program in S32DS3.4?

When I use [step into] to debug the code, it worked. But when I use [step over], reset will occur.

Keane_0-1665630815320.png

Regards,

Keane

 

0 Kudos
1,458 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

if it works when stepping the code, it's caused by read-while-write error, most likely.

lukaszadrapa_0-1665990579196.png

You can try to disable interrupts when generating the MAC.

Regards

Lukas

0 Kudos
1,453 Views
Keane
Contributor I

Hi Lukas

Yes, It was casued by interrupts, which I verified earlier today. I've known the reason for reset (RCM_SRS[LOCKUP]) through function "Mcu_GetResetReason", and also found the way to figure it as you said before, too.

path:已解决: use CSEC_DRV_GenerateMACAddrMode to generate CMAC ... - NXP Community

Regards

Keane

0 Kudos
1,511 Views
Keane
Contributor I

Hi Lukas

Sorry for that I didn't describe my iusses clearly.

Here is my code.

lQLPJxbFeQwCEG4VzQKBsIV8Wefhr38iA0SbFZrAQAA_641_21.png_620x10000q90.jpg

lQLPJxbFeQtpgscbzQL1sHumDfvI4T1pA0SbFZ2AQAA_757_27.png_620x10000q90.jpg

lQLPJxbFeSF3PthuzQIEsCcPzoXhWyM3A0SbOVKAiQA_516_110.png_620x10000q90.jpg

lQLPJxbFeSF3PMF-zQH3sN0pYdMRIckiA0SbOTjAQAA_503_126.png_620x10000q90.jpg

When the data length is over 1024 bytes, reset will occur.

I don't know why there is such a limit.

Thanks for your help again.

Best wishes.

Keane

 

 

0 Kudos
1,557 Views
Keane
Contributor I

Hi Lukas

Thanks for your reply again. It really helps me a lot.

Last week I generated my own MAC and stored it in Nvram during DEBUG CASE, but I still encountered some issues in practice.

a) I want to calculate MAC for application area like the following picture. The way I got my own MAC is to read data from FLASH ROM to buffer first, then use "Csec_GenerateMac" to calculate MAC for buffer. Is there other method free from reading from FLASH ROM firstly? (I tried to use header address of application as formal parameter, but it didn't work till I read it to buffer.)

b) Is there limited length of "Csec_GenerateMac" to calculate MAC? I tried some cases, but they didn't work when length >0x3B0. (Not very accurate, just vague data).

c) If I want to calculate MAC for application area like following picture through using header address of application as formal parameter, what am I supposed to do?

Keane_0-1665147718646.png

Best regards,

Keane

 

0 Kudos