C#实现ICAO 9303安全报文时APDU结果不符问题排查

预期APDU结构为 Header Lc' '87' L '01' 'Encrypted Data' Le'（Header固定为0c a4 04 0c），以下是针对性排查方向：

1. 检查Lc'的计算与编码 #

• Lc'是后续所有数据域（包含87标签、L长度值、01、加密数据）的总字节数，确认是否计算了全部部分的长度之和，而非仅加密数据长度。
• 验证Lc'的BER-TLV编码规则：总长度≤127时用单字节；超过则用多字节格式（首字节最高位设为1，后续字节表示长度）。

2. 验证TLV标签与长度的正确性 #

• 确认87标签是以0x87字节形式加入APDU，而非字符串或其他错误格式。
• 检查L的取值：它是01+加密数据的总长度，确保计算准确（比如01占1字节，加密数据占N字节，L应为1+N）。

3. 加密数据的拼接逻辑 #

• 检查代码是否将0x01明文常量与加密后的数据正确拼接，再作为87标签的取值部分，避免漏加01或拼接顺序错误。
• 确认加密范围：是否用PACE认证后的SM密钥对01+原始APDU数据整体加密，而非仅加密原始数据部分。

4. Le'的处理 #

• 如果预期APDU包含Le'，确认是否正确添加对应字节（比如无响应数据时设为0x00，或按需设置具体长度），避免遗漏或错误编码。

5. 对比参考实现与日志 #

• 把C#代码生成的中间数据（加密前的待加密数据、各TLV段字节数组）和PlatinumReader日志的对应部分逐字节对比，定位差异起始步骤。
• 对照Java代码的关键逻辑：重点看TLV组装、长度计算、加密数据拼接的细节，比如Java的ByteBuffer操作与C#的MemoryStream/byte[]操作的差异。

6. 调试输出关键节点数据 #

在代码中添加调试打印，输出以下内容的十六进制形式：

• 待加密的原始数据（01+原始APDU命令数据）
• 加密后的字节数组
• 组装后的87标签完整TLV段
• 最终生成的整个APDU字节数组
  通过逐段验证快速定位缺失或错误部分。

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