持久内存与安全机制 - 第391页
非常好，我们继续深入分析 《NVM Express® Base Specification Revision 2.0b》第 8.13.5.2 小节，即：
🔐 DH-HMAC-CHAP Authentication Protocol Descriptor（认证协议描述符）
目的：在
AUTH_Negotiate消息中，主机需要通过此结构向控制器声明：
- 它支持哪种认证协议（例如 DH-HMAC-CHAP）
- 支持哪些哈希函数（HashIDList）
- 支持哪些 Diffie-Hellman 群组（DHgIDList）
该结构体定义在 图 445，我们来逐字段详解。
📘 一、DH-HMAC-CHAP 协议描述符结构（图 445）
| 字节范围 | 字段 | 说明 |
|---|---|---|
0 |
AuthID |
设置为 01h，表示使用 DH-HMAC-CHAP 协议 |
1 |
Reserved |
保留，设置为 0h |
2 |
HALEN |
HashIDList 的元素数量（值范围 1~30） |
3 |
DHLEN |
DHgIDList 的元素数量（值范围 1~30） |
4 ~ 3+HALEN |
HashIDList[] |
列出支持的哈希函数 ID（见图 446） |
4+HALEN ~ 33 |
Padding | 补零对齐 |
34 ~ 33+DHLEN |
DHgIDList[] |
列出支持的 DH 群组 ID（见图 447） |
34+DHLEN ~ 63 |
Padding | 补零对齐到 64 字节末尾 |
✅ 注意：整个结构总长度固定为 64 字节。中间的
Padding以0h填充未使用部分。
🔑 二、支持的哈希函数列表（图 446）
| Identifier | 哈希算法 | 输出长度 | HMAC 块大小 | 参考 |
|---|---|---|---|---|
01h |
SHA-256 | 32 字节 | 64 字节 | [RFC 6234] |
02h |
SHA-384 | 48 字节 | 128 字节 | RFC 6234 |
03h |
SHA-512 | 64 字节 | 128 字节 | RFC 6234 |
00h, 04h–DFh, FFh |
保留（不可用） | - | - | - |
E0h–FEh |
厂商自定义（Vendor Specific） | - | - | - |
🔸规范要求：主机和控制器必须至少支持
SHA-256（01h）
🧠 三、构造样例：典型 AUTH_Negotiate 消息中的协议描述符
假设主机支持：
- Hash 函数：SHA-256 (
01h), SHA-512 (03h) - DH 群组：Group 14 (
01h), Group 19 (02h)
则：
| 字节 | 内容 | 含义 |
|---|---|---|
0 |
01h |
使用 DH-HMAC-CHAP 协议 |
1 |
00h |
保留 |
2 |
02h |
有两个 HashID |
3 |
02h |
有两个 DHgID |
4 |
01h |
SHA-256 |
5 |
03h |
SHA-512 |
6-33 |
00h |
Padding |
34 |
01h |
DH Group 14 |
35 |
02h |
DH Group 19 |
36-63 |
00h |
Padding |
🔍 四、工作原理与使用逻辑
- 主机生成描述符：
- 用于表示：我支持哪些算法，你（控制器）可以从中选择。
- 控制器从中选择：
- 若全部不满足要求：返回
AUTH_Failure1，解释为 “协议不可用”。 - 双向匹配成立后：
- 控制器发送
DH-HMAC-CHAP_Challenge消息，指定选中的 HashID 和 DHgID，继续认证流程。
⚠️ 五、设计建议（安全性与兼容性）
| 建议 | 原因 |
|---|---|
总是包含 01h（SHA-256） |
保证最小兼容性 |
| 支持多种 Hash 和 DH 组 | 提高兼容性，适配更多控制器 |
按需使用强哈希如 SHA-512 |
增强安全性，避免碰撞攻击 |
| DH 群组应选取 MODP 2048+ | 防止中间人攻击与弱密钥空间 |
如果你需要，我可以继续带你分析：
- 🔐
DH-HMAC-CHAP_Challenge,Reply,Success消息结构（图 448~450） - 💡
R1/R2计算公式及验证逻辑 - 🔗 如何用
DH 共享密钥推导出 TLS PSK 建立后续安全通道
是否需要我继续？我们可以图文并茂地梳理 DH-HMAC-CHAP 完整通信认证全流程 💬