cross-browser - saber - pila para placa madre

¿Arquitecturas para acceder a la tarjeta inteligente desde un navegador genérico? O: ¿Cómo salvar la brecha entre el navegador y la pila de PC/SC? (10)

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

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

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

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

Este complemento está en desarrollo activo, así que no dude en enviar cualquier informe y solicitud.

¿Cuáles son las posibles arquitecturas 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 el mínimo problema de instalación para el usuario final? El servidor debe poder al menos emitir APDUs 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 pila de PC / SC en funcionamiento, completa con el lector de tarjetas inteligentes. Esa es una suposición razonable, al menos en Windows desde XP, OS X moderno y Unixes.

Hasta ahora he identificado las siguientes opciones:

Algunos ActiveX personalizados. Eso es lo que utiliza 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 cumple con el requisito del "navegador genérico".
Actualización : ActiveX es compatible principalmente con el IE en desuso, incluido el IE11; Pero no por Edge.
Algunas extensiones de navegador PC / SC utilizan la API del complemento de Netscape, que parece ser una extensión suave de lo anterior. El único que ya estaba ubicado es SConnect , pero parece que apenas está vivo , su documentación de API (webarchive) ya no está disponible oficialmente y tiene fuertes vínculos con un proveedor de tarjetas inteligentes en particular. El principio puede ser bueno, pero hacer un complemento para cada plataforma sería mucho trabajo.
Actualización : la compatibilidad con NPAPI se elimina en muchos navegadores, incluidos Chrome y Firefox.
Un applet de Java, que se ejecuta sobre la JVM (1.) 6 o superior de Oracle, que viene con javax.smartcardio . Eso está bien desde un punto de vista funcional, bien documentado, puedo vivir con los pocos errores conocidos, pero tengo miedo de una espiral descendente irresistible con respecto a la aceptación de Java como una extensión de navegador.

¿Alguna otra idea?

Además: ¿existe alguna forma de evitar el abuso de cualquier interfaz PC / SC que tenga el navegador por parte de un servidor no autorizado (por ejemplo, presentar 3 PIN incorrectos para bloquear una tarjeta, solo por su maldad, o hacer algunas cosas aún más malvadas)?

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

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

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

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

Bueno, mi idea es: ¿por qué no dar la vuelta al servidor y modificar ese comportamiento para cargar una secuencia de datos de cosas para firmar algo cuando se inicia un apretón de manos?

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. En cambio, su certificado de la tarjeta tiene soporte para el ssl mutuo. Respondí a la source preguntas similar. ayuda

El hecho es que los navegadores no pueden comunicarse 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.

Hay decenas de complementos personalizados y de propiedad (que utilizan las tres opciones que mencionaste) para varios propósitos (la firma es la más popular, supongo) construida porque no existe un método estándar o universalmente aceptado, al menos en Europa y estoy seguro de que en otros lugares también.

Crear, distribuir y mantener el suyo será una maravilla, ya que los navegadores se publican cada mes aproximadamente y cada nueva versión cambia los trucos de la interfaz de usuario de sanboxing ir, por lo que es posible que deba ajustar su código con bastante frecuencia.

Y probablemente querría tener capacidades de GUI, al menos por pedir permiso al usuario para acceder a una tarjeta o alguna funcionalidad en ella.

Para crear una plataforma múltiple, un complemento de navegador múltiple, se podría usar algo como firebreath .

Personalmente, no creo que la exposición de PC / SC a la web sea buena. PC / SC es, por naturaleza, un protocolo de bajo nivel que, al exponerlo, también podría exponer el acceso a 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 de estilo plugin.sendAPDU () de javscript (o simplemente envolver todo el API PC / SC y dejar que el llamador de javascript se encargue del 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 generalmente se debe a deficiencias de corriente agudas.

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

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

Está sucio, pero si es aceptable / viable instalar un servicio / demonio de puente en la máquina cliente, entonces puede escribir un servicio de puente local (por ejemplo, en python / pyscard) que expone la tarjeta inteligente a través de una interfaz REST, y luego tenga 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 Smart Card Connector provista por Google que incluye el puerto PC / SC-Lite y el controlador CCID genérico.

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

Entonces, en lugar de reescribir toda la pila (comenzando desde el nivel más bajo: USB sin procesar), ahora los desarrolladores pueden codificar solo la parte que funciona sobre la API de PC / SC, que está expuesta por la aplicación Connector.

Hay 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 "problemas mínimos de instalación" como se requiere en la pregunta original. Puedes ver un ejemplo de uso visitando http://plugin.cardid.org

WebCard se ha probado en IE 8 a 11, Chrome y Firefox en Windows y en Chrome y Safari en Mac OS X. Ya que es solo una envoltura para PC / SC, requiere en Mac OS X la instalación de los Servicios de SmartCard desde http: // smartcardservices.macosforge.com

Para su primera pregunta, tengo pocas esperanzas: o está satisfecho con un pequeño subconjunto de la funcionalidad de la tarjeta inteligente (como la firma de correo electrónico o PDF), entonces puede usar un software ya hecho (como PKCS), mantenido de manera ideal por el compañía de tarjetas inteligentes, o si 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 alguna esperanza.

1) Tenga en cuenta que algunas especificaciones (p. Ej., ICAO / German BSI TR-3110) solicitan un método en el que el PIN no está bloqueado, pero utiliza una cantidad de tiempo considerable tan pronto como el contador de errores llega a 1 antes de responder. El intento final debe habilitarse utilizando un comando diferente, de lo contrario no se realizarán más comparaciones y se realizará un ajuste del contador de errores.

2) Simplemente proteja el comando Verificar exigiendo mensajes seguros. Las aplicaciones sensibles utilizan la mensajería segura para todo, por lo que, en primer lugar, se negocia una clave de sesión, que luego se aplica a todos los comandos y respuestas posteriores. El efecto sería que el comando sea rechazado debido a MAC incorrectos mucho antes de que se realice una comparación o modificación del contador de errores.

Tengo una configuración donde se escanea un lector de tarjetas inteligentes para iniciar sesión en un usuario. La biblioteca de PC / SC funciona muy bien en el escritorio. Alguien había mencionado el uso del compilador Emscripten ( https://github.com/kripken/emscripten ) que compila c ++ en el código JavaScript. Pero eso no funcionó bien porque algunas de las funciones que usa PC / SC solo están disponibles en el servidor. Después de mucha investigación. Finalmente, me di por vencido con una solución del lado del cliente, la API de Chrome Web Usb tampoco podía reconocer al lector.
Entonces decidí probar con SignalR y configurar un concentrador en la PC conectada al lector de tarjetas inteligentes, y este enfoque funcionó muy bien.

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

Este estándar se implementará en todos los navegadores principales y reemplazará la necesidad de aplicaciones o extensiones de terceros para tarjetas Smard :-)

¡Así que la nueva respuesta es SÍ!

Y la pila de arquitectura similar a OSI es:

Nota: Google anunció que abandonarán Chrome Apps en 2017.

Respuesta 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 multiplataforma, sino JavaScript programable y multiplataforma.

De todos modos, los navegadores modernos ya no soportan la API del complemento de Netscape (NPAPI). Y los applets de Java están siendo rechazados por los proveedores de navegadores.