# DCU Attestation：CEK 验 report 签名失败（证书链正常） > 面向海光 DCU / CSV 社区与固件安全侧的问题单。 > Host 侧取证与 HRK→HSK→CEK 链校验均成功；**仅 CEK 验 DCU report 签名失败**。 --- ## 1. 现象摘要 | 步骤 | 结果 | | --------------------------------------------- | -------------------------------------------------------------------------------- | | `MKFD_IOC_SECURITY_ATTESTATION`取 report | 成功，`fw_err=0`，`report_size=396` | | 按 report 内 `chip_id`下载 `hsk_cek.cert` | 成功（`https://cert.hygon.cn/hsk_cek?snumber=`） | | HRK 验 HSK | **OK** | | HSK 验 CEK | **OK** | | CEK 验 DCU attestation report | **失败**：`SM2_do_verify=0`，`r != (x1+e) mod n`（ERR\_MISMATCH / -6） | 多卡（至少 DCU 2～8）行为一致，非单卡异常。 --- ## 2. 环境与复现 * 程序：`csv/attestation/dcu_attestation_demo`（源文件 `dcu_attestation_demo.c`） * 接口：`/dev/mkfd` + `MKFD_IOC_SECURITY_ATTESTATION`（ioctl `0x17`） * 证书：本地 `hrk.cert`；运行时按 `chip_id` 拉取 HSK+CEK * 验签：国密 SM2 + SM3，userid 来自证书（证书链用 `HYGON-SSD-HRK` / `HYGON-SSD-HSK`；CEK 为 `HYGON-SSD-CEK`），对 r/s 做大小端翻转后验签（与证书验签同一套路径） 复现步骤： ```bash cd csv/attestation # 准备 hrk.cert；编译并链接 libcsv ./dcu_attestation_demo ``` --- ## 3. Report 布局（Host 侧结构体） ```c typedef struct attestation_report { uint32_t version; /* 4 */ uint8_t chip_id[CHIP_KEY_ID_LEN]; /* 16 */ uint8_t user_data[GUEST_ATTESTATION_DATA_SIZE]; /* 64 */ hash_block_t measure; /* 32 */ uint8_t reserved[128]; /* 128 */ uint32_t sig_algo; /* 4 */ uint32_t sig_usage; /* 4 */ union { uint32_t sig1[ECC_POINT_SIZE*2/SIZE_INT32]; ecc_signature_t ecc_sig1; /* 144 (r||s 各 72 字节槽位) */ }; } attestation_report_t; /* sizeof ≈ 396，与固件 report_size 一致 */ ``` 默认验签范围（demo 原始逻辑）： ```c /* sizeof(report) - sizeof(ecc_sig1) = 252 = 0xFC */ csv_cert_verify((const char *)report, sizeof(*report) - sizeof(report->ecc_sig1), &report->ecc_sig1, &cek.ecc_pubkey); ``` 报告字段观测（各卡一致模式）： * `version = 0x1` * `sig_algo = 0x4`（SM2） * `sig_usage = 0x1004`（与 `KEY_USAGE_TYPE_CEK` 一致） * `measure`：**全 0** * `reserved`：全 0 * `user_data`：与请求侧随机数一致（nonce 回显正常） --- ## 4. 实测样例（单卡精简） 以 **DCU 7 / chip\_id=**`TCA24010040601` 为例（其余卡同模式）。 ### 4.1 Report 摘要 ``` Node 7 gpu: 35401 report_size=396 fw_err=0x0 version=0x1 chip_id: TCA24010040601 measure: all 0x00 sig_algo=0x4 sig_usage=0x1004 signature r (固件输出字节序，验签前会 invert): D2 69 15 74 42 FC FB 02 30 47 7A 02 DC 3A D4 15 55 0C 7C 32 68 1B 9C E9 1A AA 49 06 ED 55 7C 84 signature s: 3F 18 6B 2D CB 90 36 3A E1 36 63 72 FB 22 D3 A3 17 E3 A9 EC F9 E7 EB 68 0F 5F DE D2 FF 0F 48 CE ``` signed data 前 16 字节： ``` 01 00 00 00 20 20 54 43 41 32 34 30 31 30 30 34 ``` （`version` LE + `chip_id` 前有空格填充，与结构体布局一致。） ### 4.2 证书链（通过） ``` [chain] hsk.key_usage=0x13 [chain] cek.pubkey_usage=0x1004 [chain] cek.sig1_usage=0x13 [chain] cek.sig2_usage=0x1000 [chain] cek.pubkey.curve_id=0x3 [SM2] verify OK # HRK → HSK [SM2] verify OK # HSK → CEK ``` CEK 公钥（该 chip，验签失败时使用的 Q）： ``` Qx=6948DA4C2C923DA69E2CC2922A1E162667096FE654D1A2C62817326C9013CF45 Qy=4B07D908525F8CD7B21EBBC7D8BEDA4CA8C6781F14CE53D9641BD1D425CCC893 userid=HYGON-SSD-CEK ``` ### 4.3 CEK 验 report（失败） ``` [SM2] msg_len=252 flags=invert_sig ZA||M [SM2] e = SM3(ZA||M): fafd501ae3f6e41ccd5f9bff97f481b3c743e14f97a5d8e94d66479dd962c1bb Signature (invert 后): r=847C55ED0649AA1AE99C1B68327C0C5515D43ADC027A473002FBFC42741569D2 s=CE480FFFD2DE5F0F68EBE7F9ECA9E317A3D322FB726336E13A3690CB2D6B183F ERR_MISMATCH: SM2_do_verify=0, r!=(x1+e) mod n cek verify report fail ``` --- ## 5. 额外排查（已排除 Host 参数问题） 在保持 **同一 CEK 公钥** 的前提下，对签名范围与摘要模式做了穷尽扫描，**全部**返回同一 mismatch： | signed\_len | 含义（相对结构体前缀） | | ----------- | ----------------------------------------------- | | 84 | version + chip\_id + user\_data | | 116 | + measure | | 180 | 对齐 CPU CSV `ATTESTATION_REPORT_SIGNED_SIZE` | | 244 | + reserved | | 248 | + sig\_algo | | 252 | + sig\_usage（当前默认，0xFC） | 每种长度 × 下列 4 种模式： * invert + SM2 ZAM（证书默认） * noinvert + ZAM * invert + 裸 SM3(M) * noinvert + 裸 SM3(M) 结果示例： ``` len= 84 invert+ZA / noinvert+ZA / invert+SM3(M) / noinvert+SM3(M) -> fail (-6) len=116 ... -> fail (-6) len=180 ... -> fail (-6) len=244 ... -> fail (-6) len=248 ... -> fail (-6) len=252 ... -> fail (-6) ``` 若仅是「签了前 N 字节」或「r/s 字节序 / 是否带 ZA」问题，上述组合中应至少有一组通过。 实际全部 `r!=(x1+e) mod n`，强烈指向：**消息摘要或验签公钥与固件签名私钥不匹配**（密钥身份问题，而非局部布局长度问题）。 --- ## 6. 多卡对照 | Node | gpu\_id | chip\_id | 链校验 | CEK 验 report | measure | | ---- | ------- | -------------- | ------ | ------------- | ------- | | 2 | 58787 | TCA23806041001 | OK | fail -6 | 全 0 | | 3 | 875 | TBY31710060801 | OK | fail -6 | 全 0 | | 4 | 41232 | TCA24003040701 | OK | fail -6 | 全 0 | | 5 | 52952 | TCA24007040301 | OK | fail -6 | 全 0 | | 6 | 27777 | TCA24625070401 | OK | fail -6 | 全 0 | | 7 | 35401 | TCA24010040601 | OK | fail -6 | 全 0 | | 8 | 10358 | TBY03517070701 | OK | fail -6 | 全 0 | 各卡 CEK `Qx/Qy` 不同 → KDS 按 chip 下发证书正常，不是下错同一份 CEK。 --- ## 7. 当前判断（Host 侧） **已排除：** * ioctl / 驱动取证失败 * HRK/HSK/CEK 证书损坏或链算法实现错误（同套 SM2 路径验证书成功） * 单纯 signed\_len / r-s endian / ZA vs SM3(M) 配置错误 **最可能：** > DCU 固件对 attestation report 的签名密钥 **≠** KDS 按 `chip_id` 下发的平台 CEK 私钥。 即：Host 正用 **CPU/CSV 平台 CEK 信任链** 去验 **DCU TEE report**，但固件实际签名身份可能是另一把 DCU attestation key，或密钥注入 / 固件尚未与 KDS CEK 对齐。 `measure` 全 0 也说明当前固件 attestation 内容可能仍不完整，需一并确认产品预期。 --- ## 8. 请确认 1. **DCU attestation report 是否承诺由 KDS 该** `chip_id` **的 CEK 私钥签名？** 2. 若否：正确公钥/证书从哪里获取？验签规范（userid、signed bytes、endian）文档在哪？ 3. 若是：当前固件版本下 CEK 如何注入到 DCU？是否存在已知未对齐问题？ 4. `measure` 全 0 是否为预期？何时会填入真实度量？ 5. 是否有官方参考实现 / golden report + 对应 CEK 的验签样例可供对照？ --- ## 9. 相关代码位置（仓库内） * 取证与验签 demo：`csv/attestation/dcu_attestation_demo.c` * report 结构体、`verify_report()`、默认 `signed_len = sizeof(report) - sizeof(ecc_sig1)` * 证书与 SM2 验签：`csv/attestation/csv_sdk/csv_status.c`、`csv/attestation/csv_status.h` * KDS：`https://cert.hygon.cn/hsk_cek?snumber=` ### 默认验签调用（demo） ```c logcat("Start to verify report by CEK \n\n"); ret = csv_cert_verify((const char *)report, sizeof(*report) - sizeof(report->ecc_sig1), &report->ecc_sig1, &cek.ecc_pubkey); logcat("cek verify report %s\n", ret ? "fail" : "success"); ``` --- ## 10. 期望结论 请明确下列之一，便于 Host 侧闭环： * A. **应使用 CEK**：给出固件/密钥修复计划或正确固件版本；或 * B. **不应使用 CEK**：给出 DCU 专用证书链 / 公钥来源与验签规范。 谢谢。