2016-02-23 4 views
1

Je développe une application C++ (sur Windows 7) qui s'interface avec des lecteurs de cartes PC/SC pour effectuer certaines opérations d'authentification. Cette application est le processus enfant d'une autre application (je ne sais pas si c'est pertinent, mais ce pourrait être le cas).Carte à puce Obtenir la réponse État de retour 6D00

J'ai également une application de test autonome simple qui effectue toutes les interactions avec la carte à puce dont j'ai besoin et qui le fait avec succès. Cependant, j'ai rencontré un comportement étrange lors de l'intégration du code de cet utilitaire dans mon application principale.

En particulier, la première commande que je transmets à la carte est une commande SELECT FILE:

0x00 0xa4 0x04 0x00 ...

La réponse à cette commande est la même chose que mon utilitaire de test autonome:

0x61 0x13

Comme cela indique qu'il y a plus d'octets de réponse disponibles, j'envoie une commande GET RESPONSE:

0x00 0xc0 0x00 0x00 0x13

Cette commande échoue avec une erreur indiquant que l'instruction est valide:

0x6d 0x00

Cependant mon utilitaire de test (fonctionnant avec le même lecteur de carte et la même carte) reçoit une réponse positive (par exemple finissant en ... 0x90 0x00). Cependant, l'application de test nécessite que la carte à puce soit dans le lecteur au démarrage (c'est une application simple qui démarre, fait ce dont elle a besoin, puis existe). L'erreur que j'ai décrite pour mon application réelle ne se produit pas si la carte est dans le lecteur au démarrage (tout comme avec mon lecteur de test).

Est-ce que quelqu'un a des idées de ce qui pourrait être la source de ce problème. La carte supporte le code d'instruction donné comme en témoigne le fait que dans certaines situations elle y répondra avec succès. La carte est bonne (elle répond à la commande initiale SELECT FILE comme prévu). Je ne pense pas que ce soit un problème d'autorisations (encore une fois, cela fonctionne au démarrage). Mon application principale est multi-thread, mais toutes les interactions de cartes se produisent sur un seul thread. Je n'arrive pas. Toutes les suggestions seraient grandement appréciées. Une autre chose que j'ai remarquée est que dans le scénario réussi (par exemple avec la carte dans le lecteur lorsque l'application démarre), la réponse GET prend ~ 0.05 secondes dans le scénario infructueux (par exemple, la carte est insérée après l'application démarre) cela prend ~ 2 secondes.

+0

Vous pouvez soit essayer d'attendre quelques secondes après l'insertion de la carte dans le lecteur avant de commencer à envoyer des commandes, soit ouvrir le lecteur de carte pour un accès exclusif. Ce que vous ressentez peut être lié à Windows 7 plug-and-play pour cartes à puce avec envoie automatiquement un tas de commandes à votre carte et peut entraîner l'entrelacement de vos commandes avec ces commandes plug-and-play. –

+0

@MichaelRoland est exactement correct. En passant à l'obtention d'un handle exclusif à la carte (et en faisant une attente en cas d'échec), tout a commencé à fonctionner correctement. Merci beaucoup! – DAG

Répondre

1

Ce que vous ressentez peut être lié à Windows 7 plug-and-play pour les cartes à puce. Cette fonctionnalité plug-and-play envoie automatiquement tout un tas de commandes à une carte juste après son insertion dans le lecteur. Si votre application commence également à envoyer des commandes à ce moment-là, cela peut entraîner l'entrelacement de vos commandes avec les commandes de Plug-and-Play. Par conséquent, vous pouvez essayer d'attendre quelques secondes après l'insertion de la carte dans le lecteur avant de commencer à envoyer des commandes, ou vous pouvez ouvrir le lecteur de carte pour un accès exclusif.

Pour un accès exclusif, utilisez la valeur SCARD_SHARE_EXCLUSIVE pour le paramètre dwShareMode de SCardConnect.