HI
我们正在为 S32N55 平台开发安全调试身份验证，并且已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。
我们现在正尝试将其扩展到 CRS 功能域（HSE_DEBUG_DOMAIN_APP = 0x1B），并有以下问题：
---
[Q1] ADKP 是否可用于 CRS 功能域安全调试身份验证？
通过 HSE_OTP_FOEM_ADKP_ATTR_ID 配置 ADKP 后，是否可以使用同一个 ADKP 通过 HSE_DEBUG_CMD_APP_CHALLENGE 进行 CRS 功能域（APP）安全调试身份验证？
---
[Q2] SetOwnerDebugKeyMap() 是否需要针对每个 MU（FSS MU 与 CRS MU）单独调用？
根据 RM 对 hseOwnerDebugKeyMapConfig_t 的描述：
“这项服务由拥有该设备的 MU 为每个已安装设备的所有者单独调用。
HSE FW 会根据发送此服务请求的 MU 来假定所有者身份。
我们目前的实现仅通过 FSS MU (MU0) 调用 SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING)，映射 aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP。
- CRS 功能域身份验证是否需要通过 CRS MU 单独调用 SetOwnerDebugKeyMap()？
- 如果是这样，S32N55 上的 CRS 功能域应该使用哪个 MU 编号？
---
[Q3] 每次启动时都需要调用 SetOwnerDebugKeyMap() 吗？
RM表示：
“仅记录 numOfAuthorizationRefEntries 和 numOfAuthenticationRefEntries，
其余条目将被忽略。
这意味着密钥映射是易失性的，不会存储在非易失性存储器 (NVM) 中。这是否意味着对于 FSS 和 CRS 域，每次启动时（在授予 SU 权限之后）都必须调用 SetOwnerDebugKeyMap()？
---
[Q4] 更正 APP_CHALLENGE 的 keyRef 值
在 hseDebugAuthorizeStartCmd_t 中，keyRef 字段引用通过 hseOwnerDebugKeyMapConfig_t 映射的索引。由于我们将 aOwnerAuthRef[0] 映射为 HSE_OTP_KEY_FOEM_ADKP，因此我们发送 keyRef = 0x00 来进行 CRS 功能域身份验证。这样对吗？
---
[Q5] APP_CHALLENGE 的响应大小和数据包结构
根据 hseDebugAuthorizeProofProvCmd_t 字节映射，数据包结构始终为 32 字节（2 个数据包 x 8 个字）。HSE_CR_APP_RESPONSE_SIZE = 16U 与 HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U。
对于 APP_CHALLENGE，主机是否应该发送：
- 16 字节的 AES 加密响应 + 16 字节的零填充 = 总共 32 字节？
或者只有 16 字节？
目前，在发送 FLAG_START + DebugSignalMap(4 字节) + Response(16 字节) + FLAG_END 后，HSE2 没有响应，T32 无限期地挂起等待。当我们发送 32 字节（16 字节响应 + 16 字节零填充）时，会观察到同样的卡顿现象。
---
供参考：
- Sherpa_Cdd_AllocateChannel() 总是分配 MU0 (FSS)
- SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302)，使用 SU 权限调用
- crs_auth.cmm：DEBUG_TARGET=0x1B，OID=0xFF*16，keyRef=0x00
- AUTH_MODE_REQ 请求成功通过（已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG 信号）
- 已接收挑战码：32 字节
发送响应后，未收到来自 HSE2 的 ACK (0x4A4A4A4A)。
请参阅附件中的CMM脚本和日志以供参考。
提前谢谢您。
你好，
谢谢你的建议。应要求，我创建了一个新帖子来跟踪 CRS（APP 功能域）安全调试身份验证问题：
[S32N55 HSE2 — CRS（应用程序功能域）通过 hseDebugCardCmd_t 进行安全调试身份验证]
（请在NXP社区搜索以上标题）
这个问题目前影响了我们的客户发货计划。请您在方便的时候尽快查看一下这篇新文章。
CMM脚本（crs_auth.cmm）新帖子中附上了日志文件。
非常感谢您的及时支持。
你好，
感谢您的回复。
我们对 S32N55 上 CRS (APP) 功能域安全调试身份验证的 hseDebugCardCmd_t 实现还有其他疑问。
---
[Q1] hseDebugCardInfo_t 中的 Owner ID (ownerId) 是否与通过 hseOwnerDebugKeyMapConfig_t 配置的值相同？
我们的设备配置为单所有者场景，其中 Fss_Firmware_au8Oid[] = {0xFF * 16}。
hseDebugCardCmd_t 中的 ownerId 字段是否也应设置为 0xFF * 16？
或者它是否需要与设备所有者安装期间配置的特定值相匹配？
---
[Q2] hseDebugCardCmd_t 是否需要在 APP_CHALLENGE 之后发送，还是应该代替 hseDebugAuthorizeProofProvCmd_t 发送？
根据 RM 的说法：“对于基于 APP 的选项，调试信号仅通过调试卡身份验证启用和授权（参见 hseDebugCardCmd_t）（该字段被忽略）。”
我们目前的流程：
1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B)
2. rx_authmode → 已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG
3. APP_CHALLENGE → rx_challenge（已接收 32 字节）
4. 直接发送 hseDebugCardCmd_t（跳过 hseDebugAuthorizeProofProvCmd_t）
5. HSE2 停止响应（T32 卡在 CARD_REQUEST 的 FLAG_END 处挂起）
是否应该在发送 hseDebugCardCmd_t 之前发送 hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC)？
或者，是否应该在不发送 ProofProv 的情况下，直接在 rx_challenge 之后发送 hseDebugCardCmd_t？
---
[Q3] 使用 MAC 方案时，hseDebugCardTag_t 的正确认证标签 (authTag) 计算方法是什么？
我们正在使用：
authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11)
authTag = AES256-CMAC(key=ADKP, data=Challenge[32 字节])
authLen = 16
这个计算结果正确吗？或者 CMAC 输入是否应包含其他字段（OID、功能域映射等）？
---
[Q4] hseDebugCardCmd_t 的正确数据包结构是什么？
基于 RM 字节映射，我们目前的实现方式如下：
数据包 1（32 字节）：KRI（4 字节）+ CMD（4 字节=0x5DCDEB77）+ OID（16 字节=0xFF*16）+ AuthScheme（8 字节=CMAC）
数据包 2（32 字节）：启用调试域映射（bit27=0x08000000）+ 填充（28B）
数据包 3：debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B)
这个结构正确吗？HSE2 在接收到 OID 字段（0xFF 字节）后停止响应。
---
请问您的邮箱地址是什么？我会把用于 CRS 认证的 CMM 文件发给你。
BRs。
你好， @EddiePark
感谢你的帖子。
很高兴听到S32N55 平台的安全调试认证已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。
我会继续协助您核实新问题的详细信息。很抱歉我没有看到您提供的 CMM 脚本和日志，能否请您再次上传以便我们参考？
BR
陈银
你好， @EddiePark
感谢您的回复。
本帖中已有 6 个问题，可能需要较长时间进行调查，为了提高效率，对于其他问题，我建议另开新帖进行跟踪。
正如您所提到的，会有脚本/日志作为附件供检查，但我没有在您的帖子中看到，请问它们是否会再次上传？
BR
陈银
你好， @EddiePark
感谢您的回复。
1.我们将一如既往地尽力解答您的疑问。
2. 我理解这是一个紧急问题，但正如我之前在支持中提到的，S32N55 仍处于预生产阶段，尚未通过社区渠道提供支持（在此期间，我们建议您直接联系您的 FAE/代理商以加快效率），因此回复可能需要较长时间。此外，使用 LC advanced 进行安全调试通常处于开发后期阶段，近期相关的文档/示例仍然有限。
给您带来的不便，敬请谅解。
BR
陈银
你好， @EddiePark
感谢您的耐心等待，以下是一些初步评论供您参考。
[Q1] ADKP 是否可用于 CRS 功能域安全调试身份验证？
[评论] ：是的，用于应用程序功能域安全调试身份验证的密钥是从 hseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRef 中选择的，它可能包含 ADKP 的密钥句柄。
[Q2] SetOwnerDebugKeyMap() 是否需要针对每个 MU（FSS MU 与 CRS MU）单独调用？
[评论] ：SetOwnerDebugKeyMap() 应该绑定到设备所有者，而不是 MU。设备所有者可以包含多个群组，每个群组可以有多个 MU 实例。如果 FSS 和 CRS 属于同一设备所有者，则可以通过 CRS MU 或 FSS MU 调用。
[Q3] 每次启动时都需要调用 SetOwnerDebugKeyMap() 吗？
【评论】 ：不应该在每次启动时都调用，配置应该保存在 SYS-IMG 或熔丝中，否则设备重新上电后安全调试将失败，这不符合安全调试的设计预期。但是，我不确定应该从当前可用资源中存储此配置的哪个位置。
[Q4] 更正 APP_CHALLENGE 的 keyRef 值
在 hseDebugAuthorizeStartCmd_t 中，keyRef 字段引用通过 hseOwnerDebugKeyMapConfig_t 映射的索引。由于我们将 aOwnerAuthRef[0] 映射为 HSE_OTP_KEY_FOEM_ADKP，因此我们发送 keyRef = 0x00 来进行 CRS 功能域身份验证。这样对吗？
【备注】 ：是的，如果 ADKP 句柄是 OwnerCardAuthenticationRef 的第一个条目，并且用户想要使用 ADKP 对 CRD 调试进行身份验证，则 authKeyRef 应为 0（ADKP 句柄条目的索引）。
[Q5] APP_CHALLENGE 的响应大小和数据包结构
【注释】 ：对于应用程序调试，除了调试信号映射和挑战响应数据字段外，数据包 1 中的其他未使用数据可以填充 0。
由于有关此主题的相应文件尚未完全更新（S32N55 仍处于早期阶段），因此我们能提供的信息有限。
给您带来的不便，敬请谅解。
BR
陈银
你好，
再次感谢您一直以来的支持。我们完全理解 S32N55 仍处于预生产阶段，目前有关该主题的文档/资源有限。对于这些额外的问题，我们深表歉意。但由于我们的客户交货日期临近，而这是一个关键的障碍，我们不得不请求您提供更多指导。
我们已采纳您之前的评论（Q1-Q5）：keyRef=0x00，ADKP 在 pOwnerCardAuthenticationRef 中，数据包 1 填充为 32 字节（debugSignalMap 4B + appChallengeAuth 16B + 未使用的 12B = 0）。
但是，我们仍然卡在 ProofProv / CARD_REQUEST 阶段。我们目前的状况：
1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 返回 0x4A4A4A4A)
2. APP_CHALLENGE -> OK（已收到 32 字节挑战）
3. ProofProv (hseDebugAuthorizeProofProvCmd_t):
- 数据包 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0)
所有 32 字节数据均已通过 SDC-600 成功传输
- >>> HSE2 在此之后没有反应 <<<
SDC-600 TX 在发送约 20 字节后似乎会停止，HSE2 也不会发送任何响应帧。
请您澄清以下关于APP（CRS）功能域认证顺序的问题：
[Q1] 主机发送 APP_CHALLENGE 的 ProofProv (hseDebugAuthorizeProofProvCmd_t with appChallengeAuth) 后，HSE2 是否会向主机发送中间响应帧？或者 HSE2 保持静默，等待下一个命令？
作为参考，在 FSS 功能域中，经过 ProofProv 后，HSE2 返回 0x4A4A4A4A。我们在 APP 功能域未观察到此类响应。这是预期之内的吗？
[Q2] 对于 APP_CHALLENGE，ProofProv (hseDebugAuthorizeProofProvCmd_t) 和 CARD_REQUEST (hseDebugCardCmd_t) 之间的正确顺序是什么？
- 选项 A：APP_CHALLENGE -> ProofProv -> (HSE2 响应？)-> 卡片请求
- 选项 B：APP_CHALLENGE -> CARD_REQUEST 直接执行（APP 跳过 ProofProv）
- 选项 C：其他序列
由于 RM 指出 debugSignalMap 对于 APP 是“忽略的”，并且授权“仅通过调试卡认证”进行，那么对于 APP 功能域是否应该发送 ProofProv，或者我们应该在挑战后直接执行 CARD_REQUEST？
[Q3] 请提供从 COMM_START 到最终授权响应的 APP (CRS) 功能域安全调试身份验证的完整命令序列？
我们希望确认具体的命令顺序以及哪些命令需要 HSE2 的响应，具体如下：
COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [final response?]
任何关于 APP/CRS 功能域的参考流程或示例都将非常有帮助，因为当前的行为（ProofProv 后 HSE2 静默）与 FSS 功能域的流程不符。
非常感谢您的理解和支持。
顺祝商祺！
你好，
谢谢你的回复，我明白了，以后也会一直明白。我们会尽力提供支持。
1.我已经下载了您在另一个帖子“S32N55 HSE2 CRS 功能域身份验证未完成”中分享的 cmm 和 auth 文件，它们与当前使用的文件相同吗？
2. 对于您稍后提出的问题：
[Q1] hseDebugCardInfo_t 中的 Owner ID (ownerId) 是否与通过 hseOwnerDebugKeyMapConfig_t 配置的值相同？
【评论】 ：是的，hseDebugCardInfo_t 的 OID 就是设备所有者安装服务的 ownerid。
[Q2] hseDebugCardCmd_t 是否需要在 APP_CHALLENGE 之后发送，还是应该代替 hseDebugAuthorizeProofProvCmd_t 发送？
[注释] ：应在发送 CARD_REQUEST 之前发送 hseDebugAuthorizeProofProvCmd_t。
[Q3] 使用 MAC 方案时，hseDebugCardTag_t 的正确认证标签 (authTag) 计算方法是什么？
【备注】：抱歉，API RM 中没有关于这方面的明确描述。但是 App 功能域 的身份验证标签可能不会使用收到的质询，该质询用于 hseDebugAuthorizeProofProvCmd_t。对于用户的 CRS 功能域调试，可能是authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t)。您可以尝试一下。
[Q4] hseDebugCardCmd_t 的正确数据包结构是什么？
【备注】： hseDebugCardCmd_t 的结构可以参考 HSE FW API 接口中的注释，这比 HSE FW API RM 中的描述更清晰。通过检查您分享的原始脚本，我们发现 hseDebugCardCmd_t 的结构存在一些错误，请参见附件。
如果您觉得其他文件不方便在帖子中分享，可以通过私信发送给我。
BR
陈银