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.
Solved! Go to Solution.
Hi Keane,
if it works when stepping the code, it's caused by read-while-write error, most likely.
You can try to disable interrupts when generating the MAC.
Regards
Lukas
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
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
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
Hi Lukas
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
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.
Regards,
Keane
Hi Keane,
if it works when stepping the code, it's caused by read-while-write error, most likely.
You can try to disable interrupts when generating the MAC.
Regards
Lukas
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
Hi Lukas
Sorry for that I didn't describe my iusses clearly.
Here is my code.
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
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?
Best regards,
Keane