智能卡获取响应返回状态6D00 [英] Smart Card Get Response Returns Status 6D00

查看:2445
本文介绍了智能卡获取响应返回状态6D00的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个C ++应用程序(在Windows 7上),该应用程序与PC / SC读卡器连接,以执行一些身份验证操作。这个应用程序是另一个应用程序的子进程(我不知道是否相关,但它可能是)。

I am developing a C++ application (on Windows 7) which interfaces with PC/SC card readers to perform some authentication operations. 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.

特别是我发送到卡的第一个命令是SELECT FILE命令:

In particular the first command I send to the card is a SELECT FILE command:

0x00 0xa4 0x04 0x00 ...

对此命令的响应与我的独立测试实用程序相同:

The response to this command is the same as with my standalone test utility:

0x61 0x13

这表示有更多的响应字节可用,我发送一个GET RESPONSE命令:

As this indicates that there are more response bytes available, I send a GET RESPONSE command:

0x00 0xc0 0x00 0x00 0x13

此命令失败并显示指示无效的错误:

This command fails with an error indicating that the instruction is invalid:

0x6d 0x00

但是我的测试实用程序(使用相同的读卡器和相同的卡)接收成功的响应(例如结束于 ... 0x90 0x00 )。然而,测试应用程序要求智能卡在读取器启动时(它是一个简单的应用程序,它开始,它需要,然后存在)。

However my test utility (running with the same card reader and the same card) receives a successful response (e.g. ending in ... 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).

没有任何人有任何想法,我的实际应用程序中描述的错误不会发生,如果卡在启动时在读卡器可能是这个问题的根源。该卡确实支持给定的指令代码,这由在某些情况下它将成功地响应的事实证明。卡是好的(它按预期响应初始的SELECT FILE命令)。我不认为它是一个权限问题(再次,它在启动时工作)。我的主要应用是多线程,但所有卡交互发生在单个线程。我失去了。任何建议都将非常感激。

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). 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.

我注意到的另一件事是,在成功的情况下(例如,当应用程序启动时,读卡器中的卡)GET RESPONSE需要〜0.05秒,而在不成功的情况下(例如,卡在应用程序启动后的某个时间插入)花费大约2秒钟。

Another thing I've noticed is that in the successful scenario (e.g. with the card in the reader when the application starts up) the GET RESPONSE takes ~0.05 seconds while in the unsuccessful scenario (e.g. the card is inserted sometime after the application starts up) it takes ~2 seconds.

推荐答案

您体验到的可能与智能卡的Windows 7即插即用有关。这种即插即用功能在卡插入读卡器后自动向卡发送一大堆命令。如果你的应用程序也在那时开始发送命令,这可能导致你的命令与即插即用的命令交错。

What you experience might be related to Windows 7 plug-and-play for smartcards. 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.

对于独占访问对 SCardConnect 的参数 dwShareMode 使用值 SCARD_SHARE_EXCLUSIVE

For exclusive access, use the value SCARD_SHARE_EXCLUSIVE for the parameter dwShareMode of SCardConnect.

这篇关于智能卡获取响应返回状态6D00的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆