- Home
- :
- Product Forums
- :
- MPC5xxx
- :
- MPC5777C CSE Miyaguchi-Preneel Compression CMD

Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

MPC5777C CSE Miyaguchi-Preneel Compression CMD

06-16-2017
08:23 AM

773 Views

ellenwang

Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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).

5 Replies

06-19-2017
04:14 AM

62 Views

petervlna

NXP Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

06-26-2017
06:05 AM

62 Views

ellenwang

Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

06-22-2017
07:46 AM

62 Views

ellenwang

Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

04-13-2020
04:51 AM

62 Views

mohan_ashwin

Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

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

06-20-2017
07:57 AM

62 Views

ellenwang

Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Thanks Peter!

Ellen