2387055_en-US

[#1]

S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

Hi

We are working on Secure Debug authentication for the S32N55 platform and have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600.

We are now trying to extend this to the CRS domain (HSE_DEBUG_DOMAIN_APP = 0x1B) and have the following questions:

---

[Q1] Is ADKP usable for CRS domain Secure Debug authentication?

After provisioning ADKP via HSE_OTP_FOEM_ADKP_ATTR_ID, is it possible to use the same ADKP for CRS domain (APP) Secure Debug authentication via HSE_DEBUG_CMD_APP_CHALLENGE?

---

[Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)?

Per the RM description of hseOwnerDebugKeyMapConfig_t:
"This service is called for each installed device owner individually from an owning MU.
HSE FW assumes the owner identity based on the MU this service request is sent to."

Our current implementation calls SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) only through FSS MU (MU0), mapping aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP.

- Is a separate SetOwnerDebugKeyMap() call required through the CRS MU for CRS domain authentication?
- If so, which MU number should be used for the CRS domain on S32N55?

---

[Q3] Does SetOwnerDebugKeyMap() need to be called on every boot?

The RM states:
"Only the numOfAuthorizationRefEntries and numOfAuthenticationRefEntries are logged,
rest of the entries are ignored."

This implies the key mapping is volatile and not stored in NVM. Does this mean SetOwnerDebugKeyMap() must be called on every boot (after SU rights are granted) for both FSS and CRS domains?

---

[Q4] Correct keyRef value for APP_CHALLENGE

In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct?

---

[Q5] Response size and packet structure for APP_CHALLENGE

Per hseDebugAuthorizeProofProvCmd_t byte map, the packet structure is always 32 bytes (2 packets x 8 words). HSE_CR_APP_RESPONSE_SIZE = 16U vs HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U.

For APP_CHALLENGE, should the host send:
- 16 bytes of AES-encrypted response + 16 bytes of zero padding = 32 bytes total?
- Or only 16 bytes?

Currently, after sending FLAG_START + DebugSignalMap(4 bytes) + Response(16 bytes) + FLAG_END, HSE2 does not respond and T32 hangs waiting indefinitely. When we send 32 bytes (16-byte response + 16-byte zero padding), we observe the same hang.

---

For reference:
- Sherpa_Cdd_AllocateChannel() always allocates MU0 (FSS)
- SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302), called with SU rights
- crs_auth.cmm: DEBUG_TARGET=0x1B, OID=0xFF*16, keyRef=0x00
- AUTH_MODE_REQ passes successfully (HSE_DEBUG_WAITING_RESPONSE_TO_CHG received)
- Challenge received: 32 bytes
- After sending Response, no ACK (0x4A4A4A4A) received from HSE2

Please see the attached CMM script and log for reference.

Thank you in advance.

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

Hello,

Thank you for your suggestion. As requested, I have created a new post to track the CRS (APP domain) Secure Debug authentication issue:

[S32N55 HSE2 — CRS (APP Domain) Secure Debug Authentication via hseDebugCardCmd_t]
(Please search the title above in NXP Community)

This issue is currently blocking our customer delivery schedule. Could you please review the new post at your earliest convenience?

The CMM script (crs_auth.cmm) and log file are attached in the new post.

Thank you very much for your urgent support.

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

Hello,

Thank you for your response. 

We have additional questions regarding hseDebugCardCmd_t implementation for CRS (APP) domain Secure Debug authentication on S32N55.

---

[Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t?

Our device is configured in single-owner scenario where Fss_Firmware_au8Oid[] = {0xFF * 16}.
Should the ownerId field in hseDebugCardCmd_t also be set to 0xFF * 16?
Or does it need to match a specific value provisioned during Device Owner installation?

---

[Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t?

Per RM: "For APP based options, debug signals are enabled and authorized only through the debug cards authentication (see hseDebugCardCmd_t)(field is ignored)."

Our current flow:
1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B)
2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG received
3. APP_CHALLENGE → rx_challenge (32 bytes received)
4. hseDebugCardCmd_t sent directly (skipping hseDebugAuthorizeProofProvCmd_t)
5. HSE2 stops responding (T32 hangs at FLAG_END of CARD_REQUEST)

Should hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) be sent BEFORE hseDebugCardCmd_t?
Or should hseDebugCardCmd_t be sent directly after rx_challenge without ProofProv?

---

[Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme?

We are using:
authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11)
authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes])
authLen = 16

Is this the correct computation? Or should the CMAC input include additional fields (OID, domain map, etc.)?

---

[Q4] What is the correct packet structure for hseDebugCardCmd_t?

Based on the RM byte map, our current implementation:
Packet 1 (32 bytes): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC)
Packet 2 (32 bytes): enabledDebugDomainMap(bit27=0x08000000) + padding(28B)
Packet 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B)

Is this structure correct? HSE2 stops responding after receiving the OID field (0xFF bytes).

---

Could you please let me know your email?  I will send you cmm file for crs auth.

BRs.

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

Hello, @EddiePark 

Thanks for your post.

Pleased to hear that the Secure Debug authentication for the S32N55 platform have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600.

I will continue to help check with the details for your new issues, sorry that I did not see the attached CMM script and log for reference, would you mind uploading them again to share with us?

BR

Chenyin

Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP

Hello, @EddiePark 

Thanks for your reply.

There are already 6 questions existed in this post, and may take a relative long time to investigate, in order for improving the efficiency,  for additional questions, I suggest creating a new post to track.

And as you mentioned, there would be scripts/logs attached for checking, but I do not see in your post, may I know if they would be uploaded again?

BR

Chenyin