Architectures pour accéder à une carte à puce à partir d'un navigateur Générique? Ou: comment passer du navigateur à la pile PC/SC?

quelles sont les architectures possibles côté client pour accéder à une Carte À Puce locale à partir d'un navigateur Générique (connecté à un serveur par http(s)), de préférence à partir de Javascript, avec le minimum de problèmes d'installation pour l'utilisateur final? Le serveur doit pouvoir au moins émettre les APDUs de son choix à la carte (ou peut-être en déléguer une partie au code client qu'il génère). Je suppose la disponibilité du côté client d'une pile PC/SC, complète avec lecteur de Carte À Puce. C'est une hypothèse raisonnable au moins sur Windows depuis XP, OS X moderne et Unixes.

j'ai identifiés jusqu'à présent l'une des options suivantes:

  1. Certains ActiveX personnalisé. C'est ce que mon application existante utilise (Nous l'avons développé en interne), le déploiement est assez facile pour les clients avec IE une fois qu'ils obtiennent l'autorisation d'installer L'ActiveX, mais il ne correspond pas à l'exigence "navigateur Générique".

    mise à Jour: ActiveX est principalement supporté par le IE dépréciée, y compris IE 11; mais pas par bord.
  2. une extension du navigateur PC/SC utilisant L'API du Plugin Netscape, qui semble être une extension en douceur de ce qui précède. Le seul prêt-à-porter que j'ai trouvé est SConnect, mais il me semble à peine vivant, son API documentation (webarchive) n'est plus disponible officiellement et a des liens étroits avec un fournisseur de Cartes À Puce particulier. Le principe peut être agréable, mais faire un tel plugin pour tous plate-forme serait beaucoup de travail.

    mise à Jour: le support NPAPI est abandonné par de nombreux navigateurs, dont Chrome et Firefox.
  3. une Applet Java, qui court sur la JVM D'Oracle (1.)6 ou mieux, qui vient avec javax.smartcardio. C'est très bien d'un point de vue fonctionnel, bien documenté, je peux vivre avec les quelques bugs connus, mais j'ai peur d'une spirale vers le bas irrésistible en ce qui concerne l'acceptation de Java-comme-un-navigateur-extension.

une autre idée?

aussi: y a-t-il un moyen d'empêcher l'abus de l'interface PC/SC que possède le navigateur par un serveur corrompu (par exemple, en présentant 3 fausses broches pour bloquer une carte, juste pour la méchanceté de celle-ci; ou en faisant des choses encore plus maléfiques).

44
demandé sur fgrieu 2013-04-04 13:14:19

10 réponses

mise à Jour (8/2016): une nouvelle API pour le Web appelée API WebUSB est en cours de discussion. Vous pouvez déjà utilisé avec Chrome v54+.

cette norme sera implémentée dans tous les principaux navigateurs et remplacera le besoin d'applications ou d'extensions tierces pour les cartes Smard: -)

donc la nouvelle réponse est oui!

et la pile d'architecture de type OSI est:

Remarque: Google a annoncé qu'ils abandonnent les Chrome Apps en 2017.

Précédente réponse:

maintenant (2015) vous pouvez créer une application Google Chrome, en utilisant le chrome.usb API.

alors vous accédez au lecteur de carte à puce via son identifiant informatique (CCID)-compatible interface.

ce n'est pas cross-browser mais JavaScript programmable et cross-plate-forme.

de toute façon, L'API de Plugin Netscape (NPAPI) n'est plus supportée par les navigateurs modernes. Et les applets Java sont rejetés par les vendeurs de navigateur.

18
répondu Supersharp 2016-08-31 21:53:25

le fait est que les navigateurs ne peuvent pas parler aux cartes à puce (cryptographiques) à d'autres fins que L'établissement de SSL.

Vous doit besoin de code additionnel, exécuté par le navigateur, pour accéder aux cartes à puce.

il y a des dizaines de plugins personnalisés et propriétaires (utilisant les trois options que vous avez mentionnées) à des fins diverses (la signature étant la plus populaire, je suppose) construits parce qu'il n'y a pas de norme ou de manière universellement acceptée, au moins en Europe et je suis sûr d'ailleurs.

la création, la distribution et la maintenance de votre propre sera une explosion, parce que les navigateurs se libèrent tous les mois et que chaque nouvelle version change les astuces de sanboxing ir UI, de sorte que vous pourriez avoir besoin d'ajuster votre code assez souvent.

et vous souhaiteriez probablement avoir des fonctionnalités GUI, au moins pour demander la permission à l'utilisateur d'accéder à une carte ou à certaines fonctionnalités.

pour créer une plate-forme multiple, plugin de navigateur multiple, quelque chose comme firebreath pourrait être utilisé.

personnellement, je ne crois pas qu'exposer PC/SC au web soit une bonne chose. PC/SC est, par nature, qute un faible niveau de protocole que lors de l'exposition de ce, vous pourriez aussi bien l'exposer accès au niveau des blocs de votre disque et de l'espoir que "les applications sur le web sont à moi seul, et ils se comportent bien" (cela devrait répondre à votre "Aussi"). Dans le même temps un shim fin comme SConnect est le plus facile à créer, pour fournir un javscript plugin.sendapdu () - code de style (ou tout simplement envelopper tous les PC / SC API et laisser l'appelant javascript prendre soin du même niveau de détails que dans PC natif/SC API cas d'utilisation).

la création d'un plugin à cet effet est généralement pilotée par lacunes.

aborder le futur (mobile etc) est une autre histoire, où des choses comme W3C webcrypto et L'API OpenMobile va probablement finalement créer quelque chose qui exposera la clé côté client conteneurs pour applications web. Si votre cible avec les cartes à puce est la cryptographie, ma suggestion est d'éviter PC / SC et d'utiliser les services de plate-forme (CryptoAPI sur Windows, Porte-clés sur OSX, PKCS#11 sur Linux)

tout type de conception a des exigences. Tout cela s'applique si vous envisagez d'utiliser touches plutôt qu'arbitraire. Si votre exigence est d'envoyer arbitrairement APDU-s, créez un plugin et suivez-le.

22
répondu Martin Paljak 2013-04-07 07:40:14

je viens de sortir un plugin bêta pour résoudre ce problème. Ce code beta est disponible ici:

https://github.com/ubinity/webpcsc-firebreath

ce plugin est basé sur le cadre firebreath et a été testé avec Fireofx et Chrome sous Linux/WinXP/Win7. Le code Source et le pack d'extension sont fournis.

l'idée de base est de fournir un accès à L'API PCSLite, puis de développer une api JS plus conviviale en plus de ce.

ce plugin est en développement actif, alors n'hésitez pas à envoyer n'importe quel rapport et demande.

7
répondu cslashm 2013-06-03 09:06:03

pour votre première question, je n'ai guère d'espoir: soit vous êtes satisfait d'un très petit sous-ensemble de fonctionnalités de carte à puce (comme la signature d'e-Mail ou de PDF), puis vous pouvez utiliser un logiciel prêt à l'emploi (comme PKCS), idéalement maintenu par la société de cartes à puce, ou vous voulez une fonctionnalité plus large et avez besoin d'investir des efforts considérables sur votre propre. PCSC est sûrement le point de départ à choisir.

au moins pour votre "Aussi:" il y a de l'espoir.

1) noter que certains SPÉCIFICATIONS (par exemple OACI / Allemand BSI TR-3110) Demander une méthode, où un NIP n'est pas bloqué, mais utilise une quantité substantielle de temps dès que le compteur d'erreur frappe 1 avant de répondre. La dernière tentative doit être activée en utilisant une commande différente, sinon aucune autre comparaison et ajustement du compteur d'erreurs n'est fait.

2) Il suffit de protéger la commande Verify en exigeant une messagerie sécurisée. Les applications sensibles utilisent la messagerie sécurisée pour tout, donc la première étape d'une clé de session est négatif, ce qui s'applique en second lieu à toutes les commandes et réponses successives. L'effet serait, que la commande est rejetée en raison de MACs incorrects longtemps avant une comparaison ou une modification du compteur d'erreur est fait.

4
répondu guidot 2013-04-04 12:54:42

il existe un autre plugin de navigateur similaire à celui proposé par @cslashm disponible à http://github.com/cardid/WebCard