2388640_zh-CN

はい

S32N55 HSE2 CRS 功能域身份验证未完成

你好，

我们正在 S32N55 上实现基于 HSE2 的安全调试，使用 SDC-600 调试认证流程（质询/响应、APP 模式、AES-256-CMAC），由 T32 CMM 主机脚本通过调试端口与 SDC-600 通信驱动。

**地位**

- **FSS 功能域**：安全调试身份验证成功完成。调试目标“0x1A”（FSS）在质询/响应交换后返回“AUTHSTATUS = 0xBBB”，确认功能域已解锁。
- **CRS 域**：身份验证未完成。我们使用调试目标“0x1B”进行 CRS（假设如此，待 HSE2 固件参考手册确认——见下文问题 1）。

**CRS 的观察行为**

1. SDC-600 COMM_START 和 SoC 信息交换正常完成。
2. 向目标“0x1B”发出 AUTH_MODE_REQ 请求，返回“AUTH_MODE = 0x0”（基于挑战），符合预期。
3. APP_CHALLENGE 请求完成；从固件收到 32 字节的挑战。
4. 我们使用 ADKP 对挑战进行 AES-256-CMAC 加密，计算响应，并发送 16 字节的 `appChallengeAuth` 响应。本次传输顺利完成，未出现传输级错误。
5. **此时，固件不会发送 `RxRESULT`。**主机脚本在等待 `rx_response_from_fw` 中的响应时停滞不前——没有 `0xF2`（失败）也没有 ACK 模式，根本没有回复。这与正常故障不同；看起来防火墙根本没有达到生成此请求响应的阶段。

**我们目前的假设**

在 FSS 端，我们调用一次 `Sherpa_Cdd_SetOwnerDebugKeyMap()` 将 OTP ADKP 注册为所有者授权/认证密钥 (`HSE_SRV_ID_DEBUG_KEY_MAPPING`)。我们怀疑此映射仅在调用恰好被分派到的 MU 通道的上下文中应用，并且对 CRS 端 HSE2 实例不可见——这可以解释为什么 CRS 的 CARD_REQUEST 会停滞而不是返回明确的失败。

**问题**

1. 在 `AUTH_MODE_REQ` 和 `CARD_REQUEST` 中，CRS 功能域的正确调试目标/功能域 ID 值是什么？我们目前假设的值为 `0x1B`；请确认或更正。
2. 是否需要按功能域/按 MU 发出 `Sherpa_Cdd_SetOwnerDebugKeyMap()` (`HSE_SRV_ID_DEBUG_KEY_MAPPING`)，还是 FSS 和 CRS 之间共享一个全局映射？如果是按功能域计费，如何为该服务选择目标用户单元/所有者？
3. `SetOwnerDebugKeyMap` 是否需要在每次启动时调用，还是映射一旦设置就永久有效（例如，与 OTP/NVM 状态相关），所以只需要调用一次？
4. `CARD_REQUEST` 中 CRS 域的预期 OID 值是什么？我们目前发送的是全部为 `0xFF`（16 字节），这与 FSS 的工作原理相同。
5. CRS 功能域的预期 `CARD_REQUEST` 数据包结构 (`hseDebugCardCmd_t`) 是什么？在 `KRI`、`OID`、`AuthScheme` 或调试功能域信号映射字段方面，它与 FSS/APP 功能域布局有何不同？
6.CRS 中 `CARD_REQUEST` 中的身份验证标签应该如何计算？是像 FSS 一样使用相同的 `debugCardInfo` 字段进行 CMAC 验证，还是 CRS 需要包含不同的字段？

任何关于 CRS 域的预期序列/值的提示都将非常有帮助——如果需要，我很乐意分享我们的 CMM 脚本和捕获的 SDC-600 字节日志。

谢谢！

Re: S32N55 HSE2 CRS domain authentication does not complete

你好， @EddiePark

感谢你的帖子。

我们已经就您之前提出的9个问题与内部团队展开了讨论，目前仍在调查中，如有任何进展，我会尽快回复。

对于新提出的问题，我将首先参照之前的问题进行检查，然后逐一展开调查。

BR

陈银