【发布时间】：2021-06-01 11:28:53
【问题描述】：
我们正忙于尝试在行驶记录仪公司智能卡和行驶记录仪之间进行远程身份验证。我们让它与我们的测试行驶记录仪一起工作，但现在我们遇到了一个实时的问题。
每当我们开始身份验证时，一切都会顺利进行，直到 Tachograph 发送一个获取响应命令：00C0000080。行驶记录仪智能卡以6D00 响应。换句话说（据我所知），行驶记录仪请求智能卡的响应。智能卡回答“支持 CLA，但 INS 无效或未编程”（在文档中找到）。
我尝试强制使用 T1 协议。不改变结果。我们尝试强制 T0 协议，智能卡不再被我的软件读取。这意味着该智能卡显然不支持 T0 协议。
有人知道这个问题是什么意思吗？
编辑
要求我按 Maarten 的命令排序，请参阅以下命令行：
- 卡给ATR：
3BDF960080B1FE451F870031C16408923201738421E0059000C5 - tacho 回复：
00A4020C020002 - 卡片回复：
9000 - tacho 回复：
00B0000009 - 卡片回复：
000103492B022104309000 - tacho 回复：
00A4040C06FF544143484F - 卡片回复：
9000 - tacho 回复：
0022C1B60A8308000DAA06111606A2 - 卡片回复：
9000 - tacho 回复：
0088000010011EBDDCAFA17487000DAA06111606A2 - 卡片回复：
9000 - tacho 回复：
00C000008000 - 卡片回复：
6700 - tacho 回复：
00C0000080 - 卡片回复：
6D00 - 所有通讯结束
对于 Maarten：您可以假设该软件工作正常。这是今天下午一辆卡车的实时数据。电子设备连接到 Tacho，我的软件（将阅读器物理插入服务器端）与电子设备通信。这个设备是由另一个程序员制造的，他向我保证，进出转速计的数据是正确通信的。我知道我的软件可以与智能卡正确通信，因为我们让它与另一张卡和转速计一起工作。
编辑#2
在发现内部验证命令出现错误后，我们尝试在内部验证命令后面强制一个十六进制字节80。这使该过程更进一步，但在读取二进制文件后仍会取消。不知道为什么会这样，但我们目前正在调查它。 APDU 在下面。
- 通讯开始，卡发送 atr：
3BDF960080B1FE451F870031C16408923201738421E0059000C5 - tacho 回复：
00A4020C020002 - 卡片回复：
9000 - tacho 回复：
00B0000009 - 卡片回复：
000103492B022104309000 - tacho 回复：
00A4040C06FF544143484F - 卡片回复：
9000 - tacho 回复：
0022C1B60A8308000DAA06111606A2 - 卡片回复：
9000 - tacho 回复：
0088000010A73D4B33337EBC3D000DAA06111606A280 - 卡片回复：
1C90A7F7796CC9B2082470504DCDCF3D3E9EEDEEE00F4AF1FCA127CC1D7B746D21C63DA4D75138B61D7715C4919B37601BF8897DB7C1DD5F58309D55B9588C007AFBA22F997523300B1351684F65AB5FA59E350295B7EE1170F934FC8AFE191E9DEEEDBF7C582D7D0709FEE0F1B44EF3C9D452AB8F25B1106B1E510EF956D6E79000 - tacho 回复：
0084000008 - 卡片回复：
2DA8A7836A6FCF1A9000 - tacho 回复：
00820000800E5EE3CBE4F16EC816E3FB198F86338604455355AC6123E1B057C9A53ED356679B4F1AE34B8A2EBD95FDD96E4707CDECA208BF22BAA6F70A3ED0CCA39FCC6199B3F959F3226E018D46029142314F25A332C1666A44E9EE3616CD19F9A7E169827C3CEDED372F49A8478BCDD97E63EE48ED695EFFC9B556E4246732BB372C9714 - 卡片回复：
9000 - tacho 回复：
00A4020C020520 - 卡片回复：
9000 - tacho 回复：
0CB000000997018B8E04F0821140 - 卡片回复：
9000 - tacho 回复：
00A4020C020501 - 卡片回复：
9000 - tacho 回复：
0CB00003099701028E046733DD55 - 卡片回复：
6688 - 所有通讯结束
如您所见，我们在内部验证命令后面手动添加了80，这使它更进一步，但仍然出错。我们现在不确定为什么会出错，欢迎任何想法和建议，说明为什么卡现在以 6688 响应，而读取的二进制文件应该只返回信息。我们现在正在考虑“Stonedidge”测速仪与“VDO”测速仪的工作方式不同。并且公司/司机没有将转速设置设置为远程CAN通信，导致错误。我会不断更新这个问题，以供以后使用以及遇到相同问题的其他人使用。
已解决（暂时）
事实证明，斯通里奇行车记录仪确实存在问题。我们认为stoneridge 需要由车间配置以启用远程认证和下载。我们有一些文件似乎证实了这一点。我不会解释这是如何完成的，因为这类信息并不适合所有人。我们今天在另一辆配备 VDO 行驶记录仪（不需要此配置）的卡车上进行了现场测试，一切正常，如附录 11 所示。如果我没有忘记，我会在配置 Stoneridge 时更新这个问题和搞定了，所以遇到这个问题的其他人也可以尝试一下。
【问题讨论】：
-
见下文第 25 页。我认为是指令无效。这可能意味着您以错误的模式（8、16、32、64）处理卡，或者您有一个小/大端问题。请参阅：dtc.jrc.ec.europa.eu/iot_doc/…
-
你检查卡返回的ATR字符串了吗？在那里你可以看到它是否支持T0 / T1等。一个online ATR decoder可以提供帮助。如果你在中间，你可以做一个完整的通信转储并检查。
-
呃，现在我们进入了一个奇怪的领域，因为如果卡表明它支持它，读者可能只是选择 T = 0。您可以在 GET RESPONSE 之前包含命令 + 数据吗？
-
是的，我是荷兰人。嗯，内部验证（INS 88）肯定应该有 128 个字节的响应（对于他们似乎仍在使用的相当弱的 1024 位 RSA 密钥）。但是，目前您得到的是零字节响应，因为阅读器软件不要求任何响应。 GET RESPONSE 在 9000 而不是 61xx 之后返回。然后你得到一个错误的长度，因为你我们看到 8000 而不是 80 作为 Lc / Le 字节。之后我们看到一个 6D00，因为之前的 6700 是命令的结尾（这是一个错误），所以它期待一个新的命令而不是一个 GET RESPONSE。至少，我是这么理解的。
-
我认为你已经解决了你当前的问题；我确信这个状态词是不相关的。请尽量在这里保持简洁；完整的调试会话是您一个人的 :) 提示：CLA = 安全消息传递？