简体繁体 English

智能卡获取响应返回状态6D00

[英]Smart Card Get Response Returns Status 6D00

原文 2016-02-23 16:31:56 5 1 c++/ smartcard/ apdu/ smartcard-reader/ pcsc

I am developing a C++ application (on Windows 7) which interfaces with PC/SC card readers to perform some authentication operations. 我正在开发一个C ++应用程序（在Windows 7上），该应用程序与PC / SC读卡器接口以执行一些身份验证操作。 This application is the child process of another application (I don't know if that's relevant, but it might be). 该应用程序是另一个应用程序的子进程（我不知道这是否相关，但可能与此相关）。

I also have a simple standalone test application which performs all the interactions with the smart card that I need and does so successfully. 我还有一个简单的独立测试应用程序，它可以与我需要的智能卡进行所有交互，并且可以成功完成。 However I have run into some odd behavior when integrating the code from this utility into my main application. 但是，将代码从该实用程序集成到我的主应用程序时遇到了一些奇怪的行为。

In particular the first command I send to the card is a SELECT FILE command: 特别是，我发送给卡的第一个命令是SELECT FILE命令：

0x00 0xa4 0x04 0x00 ...

The response to this command is the same as with my standalone test utility: 此命令的响应与我的独立测试实用程序相同：

0x61 0x13

As this indicates that there are more response bytes available, I send a GET RESPONSE command: 因为这表明有更多的可用响应字节，所以我发送GET RESPONSE命令：

0x00 0xc0 0x00 0x00 0x13

This command fails with an error indicating that the instruction is invalid: 该命令失败，并显示一条错误消息，指示该指令无效：

0x6d 0x00

However my test utility (running with the same card reader and the same card) receives a successful response (eg ending in ... 0x90 0x00 ). 但是，我的测试实用程序（使用相同的读卡器和相同的卡运行）收到成功的响应（例如，以... 0x90 0x00结尾）。 However the test application requires the smart card to be in the reader when it's started (it's a simple application which starts, does what it needs to, then exists). 但是，测试应用程序要求智能卡在启动时位于读卡器中（这是一个简单的应用程序，启动后会执行所需的操作，然后存在）。 The error I described for my actual application does not occur if the card is in the reader at startup (just like with my test reader). 如果卡在启动时位于读取器中，则不会发生我为我的实际应用描述的错误（就像测试读取器一样）。

Does anybody have any ideas what could be the source of this problem. 是否有人有任何想法可能是这个问题的根源。 The card does support the given instruction code as evidenced by the fact that under some situations it will respond to it successfully. 该卡确实支持给定的指令代码，事实证明在某些情况下它会成功对其做出响应。 The card is good (it responds to the initial SELECT FILE command as expected). 卡是好的（它按预期响应了初始的SELECT FILE命令）。 I don't think it's a permissions issue (again, it works at startup). 我不认为这是权限问题（再次，它在启动时有效）。 My main application is multi-threaded but all card interactions occur on a single thread. 我的主要应用程序是多线程，但所有卡交互均在单个线程上进行。 I am at a loss. 我很茫然。 Any suggestions would be greatly appreciated. 任何建议将不胜感激。

Another thing I've noticed is that in the successful scenario (eg with the card in the reader when the application starts up) the GET RESPONSE takes ~0.05 seconds while in the unsuccessful scenario (eg the card is inserted sometime after the application starts up) it takes ~2 seconds. 我注意到的另一件事是，在成功的情况下（例如，在应用程序启动时将卡插入读卡器中），在不成功的情况下（例如，在应用程序启动后的某个时间插入卡），GET RESPONSE大约需要0.05秒）大约需要2秒钟的时间。

1 个解决方案

What you experience might be related to Windows 7 plug-and-play for smartcards. 您遇到的情况可能与Windows 7的智能卡即插即用有关。 This plug-and-play feature automatically sends a whole bunch of commands to a card right after its inserted into the reader. 此即插即用功能在将卡插入读卡器后立即自动向卡发送一堆命令。 If your app also starts to send commands at that time, this may result into your commands getting interleaved with the commands from plug-and-play. 如果此时您的应用也开始发送命令，则可能导致您的命令与即插即用的命令交错。

Therefore, you might want to either try to wait a few seconds after the card was inserted into the reader before you start sending commands, or you open the card reader for exclusive access. 因此，您可能要尝试在将卡插入读卡器后等待几秒钟，然后再开始发送命令，或者打开读卡器以进行独占访问。

For exclusive access, use the value SCARD_SHARE_EXCLUSIVE for the parameter dwShareMode of SCardConnect . 对于独占访问，使用值SCARD_SHARE_EXCLUSIVE的参数dwShareMode的SCardConnect 。