CSEC - CMAC verify issue with various message sizes

[Vojtech]

Hello,

I face a problem with CMAC verification, if message has some specific lengths (verification fails when message length is equal to red lines):

Vojtech_4-1693550894258.png

Pls see attached pdf for details.

Do I something wrong, or should be there done some fix in "Csec_Ip.c" ?

Thanks

[Vojtech]

Hello Dan,

thanks for quick response !

I use csec driver from "Csec_Ip.c". I use copy version (not pointer version) of cmac verification function Csec_Ip_VerifyMac(). As can be seen on below printscreen so I want to verify 656/8=82 bytes (just an example).

Vojtech_1-1694153219115.png

From Csec_Ip_VerifyMac() is then called  Csec_Ip_StartVerifMACCmd() -> Csec_Ip_WriteCommandHeader()

In Csec_Ip_WriteCommandHeader() is this:

Vojtech_2-1694153379533.png

Definition CSEC_IP_FUNC_FORMAT_COPY (which is 0) is fixed here and I am not able to change it to 1. 

"Func form at" equal to 1 is used in pointer version of Csec_Ip_VerifyMacAddrMode():

Vojtech_4-1694153723203.png

But I am not using API call Csec_Ip_VerifyMacAddrMode().

So how should I change "Func form at" equal to 1 if it is internal definition of the "Csec_Ip.c" ?

Thank you

Vojtech

[DanNguyenDuy]

Hello @Vojtech,

Sorry because I have a bit confusion. You need to use "CallSeq = 0x01: 2nd through nth Function Call"

instead of use "CallSeq = 0x0".

Best regards,

Dan

[Vojtech]

Hello Dan,

I have not found any function in CSEc API for changing value of CallSeq variable.

Vojtech_0-1696855192945.pngVojtech_1-1696855214014.png

Actually CSEc driver should care about CallSeq by itself I think:

Vojtech_2-1696856659415.png

CMAC verification fails even if there is requested to verify 81-96 bytes, where page2-page7 should be sufficient (CallSeq = 0x01 is enough). What do you think about my proposed correction of CSEc driver as I wrote in attached pdf in initial question?

I can explain in the call if needed.

Thank you

[DanNguyenDuy]

Hello @Vojtech,

Sorry because my late response.

I saw your issue when I test cmac verify with 82 bytes. I created a ticket(SECRDR-1922) for this issue.

The development team will help me analyze this issue. I'm going to inform you when they analyze it completely.

Best regards,

Dan

[DanNguyenDuy]

Hello @Vojtech,

The development team confirmed this is a bug. It will be fixed on the releases in the future.

Best regards,

Dan

[Vojtech]

Hello Dan @DanNguyenDuy ,

was this issue already corrected in any release? Or would you know in what release it will be corrected?

Thank you

Vojtech

[DanNguyenDuy · Accepted solution]

Hello @Vojtech,

This issue was fixed on the S32K1XX_S32M24x_2.0.0_P03 release.

Best regards,

Dan

[DanNguyenDuy]

Hello @Vojtech,

Follow to " CMD_VERIFY_MAC" in reference manual, we have:

nxf78987_1-1697024475706.png

In your situation,  n = 1 and MESSAGE_LENGTH must be 128 bytes => you only have data from page 0 => page 6th. So, you have to fill all of data of page 7th equal to 0 to enough 128 bytes (7 pages data + 1 page with padding value).

For example:

nxf78987_2-1697024783625.png

You got issue because you wrote 7 pages instead of 8 pages - enough 128 byte (7 pages data + 1 page with padding value).

Best regards,

Dan

[Vojtech]

Hello Dan,

I am using NXP CSEc driver:

Vojtech_0-1697104543305.png

So I can use only non-static functions from Csec_Ip.c source file  (only functions from API as printscreened in previous post). So I should not anyhow directly solve filling of PRAM interface (this is done internally by NXP CSEc driver).

I just use this function for CMAC verification (I just provide as input arguments: message buffer, message size in bits, key etc.):

Vojtech_1-1697104844554.png

When I changed the code in this NXP CSEc driver (as described in the pdf attached to original post), so everything seems to work fine - but it is RTD source file, so it should not be changed by me. I can show in a call if needed. Or do I miss something?

Thanks 

 Vojtech

[DanNguyenDuy]

Hi @Vojtech,

Your issue occurred because you configured "Func form at" equal 0 for writing all of pages. This is a solution for your situation:

With the writing first page, you need to configure "Func form at" equal 0, and from next pages, you have to configure "Func form at" equal 1 to it was saved consecutive with the previous pages in the flash memory.

If you configure "Func form at" equal 0 for next pages then those pages will don't be saved don't consecutive with previous page in the flash memory and cause your issue.

Best regards,

Dan

[DanNguyenDuy]

Hello @Vojtech,

Could you send me your demo project? I'm going to check from my site.

Best regards,

Dan