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

EddiePark

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.

chenyin_h

Hello, @EddiePark

Thanks for your patience, below are some initial comments for your reference

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

[Comments]: Yes, the used key for App domain secure debug authentication is selected from the hseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRef, it could includes the ADKP 's keyhandle.

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

[Comments]: SetOwnerDebugKeyMap() should bound to the Device owner , not MU. The Device owner could includes multiple cohorts which has multiple MU instances. If FSS and CRS are included in the same device owner, it could be called by the CRS MU or FSS MU.

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

[Comments]: It should not be called on every boot, the configuration should be saved in the SYS-IMG or fuse, otherwise the secure debug will fail after repowering the device, it does not meet the design expectation of secure debug. However not sure where to store this configuration from the current available resource.

[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?

[Comments]: Yes, if ADKP handle is the first entry of OwnerCardAuthenticationRef and the user wants to use ADKP to authenticate CRD debug, the authKeyRef should be 0(The index of ADKP handle entry)

[Q5] Response size and packet structure for APP_CHALLENGE

[Comments]: For App debug, besides the debug signal map and challenge response data fileds, the other unused data in packet 1 can be filled with 0.

Since the corresponding documents are not yet updated fully for this topic(the S32N55 is still at early stage), there is limited information we would provide.

Sorry for your inconvenience.

BR

Chenyin

EddiePark

Hello,

Thank you again for your continued support. We fully understand that S32N55 is still in the pre-production phase and that documentation/resources for this topic are currently limited. We sincerely apologize for the additional questions, but as our customer delivery schedule is approaching and this is a critical blocker, we are compelled to ask for a bit more guidance.

We have applied your previous comments (Q1-Q5): keyRef=0x00, ADKP in pOwnerCardAuthenticationRef, and Packet 1 filled to 32 bytes (debugSignalMap 4B + appChallengeAuth 16B + unused 12B = 0).

However, we are still blocked at the ProofProv / CARD_REQUEST stage. Our current status:

1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 returns 0x4A4A4A4A)
2. APP_CHALLENGE -> OK (32-byte Challenge received)
3. ProofProv (hseDebugAuthorizeProofProvCmd_t):
- Packet 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0)
- All 32 bytes transmitted successfully over SDC-600
- >>> HSE2 gives NO response after this <<<

The SDC-600 TX appears to stall shortly after ~20 bytes and HSE2 never sends any response frame.

Could you please clarify the following about the APP (CRS) domain authentication sequence:

[Q1] After the host sends ProofProv (hseDebugAuthorizeProofProvCmd_t with appChallengeAuth) for APP_CHALLENGE, does HSE2 send an intermediate response frame back to the host? Or does HSE2 remain silent and wait for the next command?

For reference, in the FSS domain, after ProofProv the HSE2 returns 0x4A4A4A4A. We observe NO such response in APP domain. Is this expected?

[Q2] What is the correct ordering between ProofProv (hseDebugAuthorizeProofProvCmd_t) and CARD_REQUEST (hseDebugCardCmd_t) for APP_CHALLENGE?

- Option A: APP_CHALLENGE -> ProofProv -> (HSE2 response?) -> CARD_REQUEST
- Option B: APP_CHALLENGE -> CARD_REQUEST directly (ProofProv skipped for APP)
- Option C: some other sequence

Since RM states debugSignalMap is 'ignored' for APP and authorization happens 'only through the debug card authentication', should ProofProv be sent at all for APP domain, or should we go directly to CARD_REQUEST after the challenge?

[Q3] Could you please provide the complete command sequence for APP (CRS) domain Secure Debug authentication from COMM_START to the final authorization response?

We would like to confirm the exact order and which commands expect a response from HSE2, specifically:
COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [final response?]

Any reference flow or example for the APP/CRS domain would be extremely helpful, as the current behavior (HSE2 silent after ProofProv) does not match the FSS domain flow.

Thank you very much for your understanding and support.

Best regards,

chenyin_h

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

EddiePark

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.

chenyin_h

Hello,

Thanks for your reply, I understand, and will always. try our best to support.

1. I have downloaded the cmm and auth files you shared from the other post S32N55 HSE2 CRS domain authentication does not complete, are they still the same one currently used?

2. For your questions listed later:

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

[Comments]: Yes, the OID of hseDebugCardInfo_t is just the ownerid of Device Owner installation service.

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

[Comments]: hseDebugAuthorizeProofProvCmd_t should be sent before sending CARD_REQUEST

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

[Comments]: Sorry that no obvious description about this in API RM. But the authentication tag for App domain may not use the received challenge, the challenge is used for hseDebugAuthorizeProofProvCmd_t. For user's CRS domain debug, maybe it is authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t). You may have a try.

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

[Comments]: The structure of hseDebugCardCmd_t could be referred to the comment in HSE FW API interface which is more clear than the description in HSE FW API RM. by checking your original script shared, we found some errors about hseDebugCardCmd_t structure, see the attached word.

For any other files that you may not be conveniently shared within the post, you may send them to me via the private message

BR

Chenyin

chenyin_h

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

EddiePark

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.

chenyin_h

Hello, @EddiePark

Thanks for your reply.

1. As always, we will try our best to support your queries.

2. I understand it is a urgence issue, but as what I had mentioned in previous support, S32N55 is still in pre-production phase, it is not yet supported via the community channel, (during this period, we suggest directly contacting your FAE/Distributor to accelerate the efficiency)so it would take relative long time to reply, furthermore, the secure debug with LC advanced is usually at a relatively late stage of development, the document/samples are still limited in recent term.

Sorry for your inconvenience.

BR

Chenyin