【问题标题】:getting extra bytes 82 00 in pc/sc response在 pc/sc 响应中获得额外的字节 82 00
【发布时间】:2017-04-20 21:57:23
【问题描述】:

我正在尝试使用 pc/sc 透明会话和收发数据对象从 Sony felica 卡读取数据。

我得到的响应是没有加密的读取命令是

c0 03 00 90 00 92 01 00 96 02 00 00 97 82 00 + 数据

但根据协议,响应应该是

c0 03 00 90 00 92 01 00 96 02 00 00 97 + 数据

我无法弄清楚卡响应中附加的最后一个 82 00。

现在,当我尝试使用我得到的卡进行身份验证时

c0 03 01 6F 01 90 00

这是 pc/sc 中的错误。我想解决这些额外的字节 82 00,我相信这将解决所有需要身份验证和加密的命令的问题。

【问题讨论】:

    标签: nfc smartcard sony contactless-smartcard pcsc


    【解决方案1】:

    响应数据采用BER-TLV 编码(参见PC/SC 2.02, Part 3)。

    在 BER-TLV 编码中,有几种可能使用两个八位字节数据 0xD0D1 对标签 0x97 进行编码,例如:

    • 97|02|D0D1 -- 短格式 (see parsed)

    • 97|8102|D0D1 -- 长格式,一个八位字节,长度为 (see parsed)

    • 97|820002|D0D1 -- 长格式,有两个八位字节,长度为 (see parsed)

    • 97|83000002|D0D1 -- 长度为三个八位字节的长格式 (see parsed)

    • ...

    您的阅读器使用两个八位字节来发送 ICC 响应 数据对象的长度(这是完全有效的)。

    您应该正确解析响应...祝您好运!

    PS:上面的意思是,你截断响应的Data部分仍然包含一个额外的响应长度字节(即Len|Data

    【讨论】:

    • 是的,你是对的,但是为什么只有相互身份验证命令对 felica 失败?
    • 您能否使用完整的 APDU 跟踪更新您的问题?您使用的是哪款阅读器(因为 PC/SC 未定义 6F01 -- 最接近的是 XX 6F 00 -- 数据对象 XX 失败,没有精确诊断)?
    猜你喜欢
    • 1970-01-01
    • 2017-09-25
    • 1970-01-01
    • 1970-01-01
    • 2021-12-26
    • 2021-12-03
    • 2019-03-13
    • 1970-01-01
    • 2016-08-07
    相关资源
    最近更新 更多