WebCrypto解密NTAG424加密数据偶发失败问题求助

针对你用全0IV的AES-CBC模拟AES-ECB解密enc字段时部分payload失败的问题，以下是具体的优化思路：

1. 严格对齐AES-ECB的分组处理逻辑 #

AES-ECB是独立处理每个16字节分组，而CBC是链式处理。用全0IV模拟时，必须确保每个分组单独解密，而非把整个payload作为一个CBC流处理——很多失败案例源于误将整段数据一次性传入CBC解密，导致跨分组的链式干扰。

• 手动拆分payload为16字节的块（最后一块不足16字节则按padding规则处理）
• 对每个块单独使用全0IV执行AES-CBC解密，再拼接结果

2. 强制验证PKCS#7 Padding的正确性 #

NTAG424的加密数据默认使用PKCS#7 padding，解密后必须严格校验：

• 解密完成后，读取最后一个字节的值padLen，验证从末尾往前padLen个字节的值都等于padLen
• 若padding不合法，直接判定解密失败（多数"bad decrypt"错误源于padding校验不严谨）
• 注意：即使解密后内容看似正常，只要padding不符合规则，就说明密钥或解密流程有误

3. 确认sv1密钥派生的准确性 #

sv1密钥派生必须严格遵循AN12196 4.4.2.1的规范：

• 检查KDF输入参数是否完整：包括picc字段的UID、版本信息，以及初始密钥的正确性
• 验证密钥派生时的哈希/加密算法（如HMAC-SHA256或指定的AES变体）是否与文档一致
• 派生后将sv1密钥转换为WebCrypto的CryptoKey对象时，确保extractable和keyUsages设置正确（需包含decrypt权限）

4. 增加解密前的数据预处理校验 #

解密前先验证enc字段的长度合法性：

• AES-ECB加密后的数据长度必须是16字节的整数倍，若不是，说明数据传输或解析时已损坏
• 对比工作payload和失败payload的长度，排查是否存在解析时的字节截断或多字节读取错误

5. 调试时输出中间结果 #

在代码中增加关键步骤的日志输出（仅调试阶段使用）：

• 输出派生后的sv1密钥原始字节值
• 输出拆分后的每个加密块、解密后的每个块的字节值
• 输出解密后的完整数据及padding检查结果
  通过对比工作和失败payload的中间数据，定位是哪个块解密出错，进而排查密钥或分组处理的问题

6. 避免WebCrypto的CBC模式优化干扰 #

部分浏览器的WebCrypto实现对CBC模式有内部优化，可能影响全0IV模拟ECB的正确性：

• 手动实现AES-ECB的核心逻辑（使用WebCrypto的AES密钥进行原始块加密/解密），而非依赖CBC模拟
• 或者使用SubtleCrypto.encrypt/decrypt时，显式指定iv为new Uint8Array(16)，并确保每次解密单个块时重新创建IV对象（避免状态复用）

内容的提问来源于stack exchange，提问作者BarakChamo