¿Arquitecturas para acceder a la tarjeta inteligente desde un navegador genérico? O bien: ¿cómo cerrar la brecha del navegador a la stack PC / SC?

¿Cuáles son las architectures posibles del lado del cliente para acceder a una tarjeta inteligente local desde un navegador genérico (conectado a un servidor a través de http (s)), preferiblemente desde Javascript, con la molestia mínima de instalación para el usuario final? El servidor debe poder, al menos, emitir APDU de su elección a la tarjeta (o tal vez delegar algo de eso al código del lado del cliente que genera). Estoy asumiendo la disponibilidad en el lado del cliente de una stack de PC / SC en funcionamiento, completa con lector de tarjeta inteligente. Esa es una suposición razonable, al menos en Windows desde XP, OS X moderno y Unixes.

Hasta ahora he identificado las siguientes opciones:

  1. Algunos ActiveX personalizado. Eso es lo que usa mi aplicación existente (la desarrollamos internamente), la implementación es bastante fácil para los clientes con IE una vez que obtienen la autorización para instalar ActiveX, pero no coincide con el requisito de “navegador genérico”.
    Actualización : ActiveX es soportado principalmente por el IE obsoleto, incluido IE11; pero no por Edge.
  2. Algunas extensiones de navegador para PC / SC que usan la API Netscape Plugin, que parece una extensión sin problemas de las anteriores. El único listo listo que localicé es SConnect , pero parece apenas vivo , su documentación API (webarchive) ya no está disponible oficialmente, y tiene fuertes lazos con un proveedor de tarjetas inteligentes en particular. El principio puede ser bueno, pero crear un plugin para cada plataforma sería mucho trabajo.
    Actualización : muchos navegadores han omitido la compatibilidad con NPAPI, incluidos Chrome y Firefox.
  3. Un applet de Java, que se ejecuta sobre la JVM de Oracle (1.) 6 o superior, que viene con javax.smartcardio . Eso está bien desde un punto de vista funcional, bien documentado, puedo vivir con los pocos errores conocidos, pero temo una espiral descendente irresistible con respecto a la aceptación de la extensión Java-as-a-browser-extension.

¿Alguna otra idea?

Además, ¿hay alguna manera de evitar el uso indebido de cualquier interfaz PC / SC que tenga el navegador por parte de un servidor deshonesto (por ejemplo, presentando 3 PIN incorrectos para bloquear una tarjeta, solo por la maldad de la misma, o haciendo algunas cosas aún más malvadas).

Actualización (8/2016): se está discutiendo una nueva API para la Web llamada WebUSB API . Ya puedes usarlo con Chrome v54 + .

Este estándar se implementará en todos los navegadores principales y reemplazará la necesidad de aplicaciones de terceros o extensiones para Tarjetas Smard 🙂

¡Entonces la nueva respuesta es SÍ!

Y la stack de architecture similar a OSI es:

  • PC / SC
  • CCID v1.1
  • API de WebUSB
  • Controlador USB, es decir , libusb .

Nota: Google anotó que abandonarán las aplicaciones de Chrome en 2017.

Anwser anterior :

Ahora (2015) puede crear una aplicación Google Chrome, utilizando la API chrome.usb .

Luego accede al lector de tarjetas inteligentes a través de su interfaz compatible con CCID .

No es un navegador cruzado, sino JavaScript progtwigble y multiplataforma.

De todos modos, los navegadores modernos ya no admiten la API Netscape Plugin (NPAPI). Y los applets de Java están siendo descartados por los proveedores de navegadores.

El hecho es que los navegadores no pueden hablar con tarjetas inteligentes (criptográficas) para otros fines que no sean el establecimiento de SSL.

Necesitará un código adicional, ejecutado por el navegador, para acceder a las tarjetas inteligentes.

Existen decenas de complementos personalizados y propietarios (usando las tres opciones que mencionaste) para varios propósitos (la firma es la más popular, creo) construida porque no hay una forma estándar o universalmente aceptada, al menos en Europa y estoy seguro de que en otro lado también.

Crear, distribuir y mantener el suyo será una maravilla, porque los navegadores lanzan cada mes más o menos y cada nuevo lanzamiento cambia los trucos de la interfaz de usuario de sanboxing, por lo que es posible que deba ajustar su código con bastante frecuencia.

Y es probable que desee tener capacidades de GUI, al menos para pedir permiso al usuario para acceder a una tarjeta o alguna funcionalidad en ella.

Para crear un plugin de múltiples plataformas y múltiples exploradores, podría usarse algo como firebreath .

Personalmente, no creo que exponer PC / SC a la web sea bueno. PC / SC es por naturaleza un protocolo de bajo nivel que, al exponerlo, también podría exponer el acceso de nivel de bloque a su disco y esperar que “las aplicaciones en la web sean solo mías y se comporten bien” (esto debería responder a su “También “). Al mismo tiempo, un shim delgado como SConnect es el más fácil de crear, para proporcionar un código javascriptcript.sendAPDU () – style (o simplemente envolver toda la API de PC / SC y dejar que el llamador de JavaScript cuide el mismo nivel de detalles como en el caso de uso nativo de PC / SC API).

La creación de un complemento para este propósito suele estar motivada por deficiencias agudas de stream .

Abordar el futuro (móvil, etc.) es otra historia, donde cosas como W3C webcrypto y OpenMobile API probablemente finalmente crearán algo que exponga los contenedores de claves del lado del cliente a las aplicaciones web. Si su objective con tarjetas inteligentes es la criptografía, mi sugerencia es evitar PC / SC y usar servicios de plataforma (CryptoAPI en Windows, Keychain en OSX, PKCS # 11 en Linux)

Cualquier tipo de diseño tiene requisitos. Todo esto se aplica si estás pensando en usar claves en lugar de APDU-s arbitrarias. Si su requisito es enviar APDU-s arbitrarias, cree un plugin y simplemente vaya con él.

Acabo de lanzar un complemento beta que aborda este problema. Este código beta está disponible aquí:

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

Este complemento se basa en el marco Firebreath y ha sido probado beta con Fireofx y Chrome bajo Linux / WinXP / Win7. Se proporcionan el código fuente y el paquete de extensión.

La idea básica es proporcionar acceso a la API de PCSLite y luego desarrollar una JS-api más amigable además de esto.

Este complemento está en desarrollo activo, así que siéntase libre de enviar cualquier informe y solicitud.

Para su primera pregunta tengo pocas esperanzas: o está satisfecho con un subconjunto muy pequeño de la funcionalidad de la tarjeta inteligente (como la firma de correo electrónico o PDF), entonces puede usar algún software listo (como PKCS), mantenido idealmente por el compañía de tarjeta inteligente, o desea una funcionalidad más amplia y necesita invertir un esfuerzo considerable por su cuenta. Seguramente PCSC es el punto de partida para elegir.

Al menos para su “también”, hay algo de esperanza.

1) Tenga en cuenta que algunas especificaciones (por ejemplo, ICAO / BSI alemán TR-3110) solicitan un método, donde un PIN no está bloqueado, pero utiliza una cantidad sustancial de tiempo tan pronto como el contador de errores llegue a 1 antes de responder. El último bash debe habilitarse usando un comando diferente; de ​​lo contrario, no se realizarán más comparaciones ni ajustes del contador de errores.

2) Simplemente proteja el comando Verificar al requerir mensajes seguros. Las aplicaciones sensibles utilizan mensajes seguros para todo, por lo que en el primer paso se descuida una clave de sesión, que se aplica en segundo lugar a todos los comandos y respuestas subsiguientes. El efecto sería que el comando se rechaza debido a MAC incorrectos mucho antes de que se realice una comparación o modificación del contador de errores.

Existe otro complemento de navegador similar al propuesto por @cslashm disponible en http://github.com/cardid/WebCard . También es de código abierto y se puede instalar con “molestias mínimas de instalación” como se requiere en la pregunta original. Puede ver un ejemplo de uso visitando http://plugin.cardid.org

WebCard ha sido probado en IE 8 a 11, Chrome y Firefox en Windows y en Chrome y Safari en Mac OS X. Como es solo un envoltorio para PC / SC, requiere en Mac OS X la instalación de SmartCard Services desde http: // smartcardservices.macosforge.com

Como Chrome y Firefox van a detener el soporte de NPAPI Plugin, no hay una solución segura disponible para mantener la sesión para la lectura de la tarjeta inteligente sino que su certificado de la tarjeta tiene soporte para ssl mutua, respondí por la fuente de pregunta similar. ayuda

Está sucio, pero si es aceptable / viable instalar un daemon / servicio de puente en la máquina cliente, entonces puedes escribir un servicio puente local (por ejemplo, en python / pyscard) que expone la tarjeta inteligente a través de una interfaz REST, luego tener javascript en el navegador que media entre ese servicio local (fachada) y la API del servidor remoto.

Hablando de Chrome, ahora puede usar la aplicación de conector de tarjeta inteligente proporcionada por Google, que agrupa el puerto PC / SC-Lite y el controlador genérico CCID.

La aplicación funciona a través de la API chrome.usb , mencionada por los comentaristas anteriores.

Por lo tanto, en lugar de reescribir toda la stack (comenzando desde el nivel más bajo, USB sin procesar), ahora es posible que los desarrolladores codifiquen solo la parte que funciona sobre PC / SC API, que es expuesta por la aplicación Connector.

Clientes, clientes, clientes … complementos, … JSApis … Bueno … Por cierto, sabemos esto: todos los navegadores, cuando se comunican con servidores Apache o IIS, en realidad están firmando ” algo ” cuando se realiza un proceso de enlace https / SSL necesario.

Por ejemplo, una configuración típica de Apache como esta:

 SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +FakeBasicAuth +StdEnvVars +ExportCertData +OptRenegotiate 

Inicia una ventana emergente de PIN y el usuario debe insertar el pin de la tarjeta inteligente para continuar.

Bueno, mi idea es: ¿por qué no hacer el turno al servidor y modificar ese comportamiento para cargar una copia de seguridad de cosas para firmar algo cuando se inicia un apretón de manos?

Tengo una configuración donde se escanea un lector de tarjeta inteligente para iniciar sesión en un usuario. La biblioteca PC / SC funciona muy bien en el escritorio. Alguien había mencionado usar el comstackdor Emscripten ( https://github.com/kripken/emscripten ) que comstack c ++ en código JavaScript. Pero eso no funcionó bien porque algunas de las funciones que utiliza PC / SC solo están disponibles en el lado del servidor. Después de mucha investigación. Finalmente renuncié a una solución del lado del cliente, Chrome Web Usb API también no pudo reconocer al lector.
Entonces decidí probar signalR y configurar un hub en la PC conectada al lector de tarjetas inteligentes y este enfoque funcionó muy bien.