MPC5777C CSE Miyaguchi-Preneel Compression CMD

[ellenwang]

For the MP compression, does the input compress data length have to be  multiple of 128 bits? I didn't see this requirement on MPC5777C reference manual.

the "SHE_Funtional_Spec_V_1.1.pdf" 3.3 mentioned messages have to be preprocessed into 128 bit chunks  before feeding them to the compression algorithm. Does it handle by hardware, don't need we manually padded and parsed into 128 bit chucks, right?

I try compress 128bits, 160 bit, 256 bits, but none of that success, CSE_SR all return 0x15 (length error)

Another question is about

K1= KDF( KEYauthID, KEY_UPDATE_ENC_C ): AES-MP( KEYauthID | KEY_UPDATE_ENC_C)

if I use the MASTER_ECU_KEY, then the KEYauthID will be 0x1, I transfer it to an long word, and concatenation with 128 bits KEY_UPDATE_ENC_C, so the length is 160 bits, all the pass in address(length address, start address, output address) are aligned on 32 bit. but I still get  0x15 (length error)

In above Two cases, I don't know what part I didn't do it right, why always get 0x15 (length error).

[petervlna]

Hi,

Unfortunately experts for CSE are not participating in public community.

In order to get in touch with them you must submit a ticket on www.nxp.com.

here is link:

http://nxpcommunity.force.com/community/CommunityContextPage 

Peter

[ellenwang]

Hi Peter,

Thanks for your information, it is much clearer now.

One more question about the KDF KAuthID. If I have M1, M2 & M3 which I use to generate the MASTER_ECU_KEY, after the MASTER_ECU_KEY be loaded, I try to use this MASTER_ECU_KEY to derive KEY2 ~ KEY20. Then when I use the KDF function, the KAuthID means 128 bits from the 256-bit M2 message(the second 128 bits from M2)? or the KAuthId means before be encrypted to M2?

Another question is about the Generate M2 for Key2 ~ Key 20, for make things simple, can I treat all CID(the new counter value) be “0”, is that will be an issue for production?

Thanks very much for your help!

Ellen

[ellenwang]

Hi Peter,

Thanks very much for your reply.

Yes, I have the same question about the comment of 176, our local NXP support people give me the source code, I have a lot of question about the code.

In doc AN5418 Appendix A: K1= KDF(KAuthID, KEY_UPDATE_ENC_C) , I understand KAuthID is Key ID (0x0 ~ 0xE), but at below example code the key is 128 bits, Do they extend the 4 bits to 128 bits? Is the KAuthID not Key ID.

And the 176 is also very confuse, with length 176 bit, the 128 bits constant will only be passed in 48 bits, the remaining 80 bits will be lost.

void CSE_KDF(char *key, char *constant, char *d_key) {

char mpc_in[32];

unsigned long long mpc_len = 176;

// copy key + constant to mpc_in, 32 bits at a time

*(vuint32_t *) &mpc_in[0] = *(vuint32_t *) &key[0];

*(vuint32_t *) &mpc_in[4] = *(vuint32_t *) &key[4];

*(vuint32_t *) &mpc_in[8] = *(vuint32_t *) &key[8];

*(vuint32_t *) &mpc_in[12] = *(vuint32_t *) &key[12];

*(vuint32_t *) &mpc_in[16] = *(vuint32_t *) &constant[0];

*(vuint32_t *) &mpc_in[20] = *(vuint32_t *) &constant[4];

*(vuint32_t *) &mpc_in[24] = *(vuint32_t *) &constant[8];

*(vuint32_t *) &mpc_in[28] = *(vuint32_t *) &constant[12];

step(" MP_COMPRESS");

CSE.P[0].R= (vuint32_t) &mpc_len; /* message length (bits) address */

CSE.P[1].R= (vuint32_t) &mpc_in; /* message start address */

CSE.P[2].R= (vuint32_t) d_key; /* output address of derived key */

CSE.CMD.R= CSE_MP_COMPRESS; /* issue MP_COMPRESS command */

while (CSE.SR.R & 1) { } /* wait until CSE is idle*/

}

Should I send this question on the website? Let me know if I need follow the process.

Thanks!

Ellen

[mohan_ashwin]

The Length is 176 rather than 256 because of internal padding by MP_COMPRESS function.

[ellenwang]

Thanks Peter!

Ellen