Soluciones modernas para usar firma digital desde la web

En el mundo de los estándares web no ha habido ni hay (por ahora) un mecanismo que permita acceder a dispositivos de seguridad para poder firmar digitalmente. Mientras avanzan los esfuerzos en este sentido y con cierto retraso, en estos años han existido diversas formas no estándar para poder firmar, siendo todas ellas soluciones propietarias de cada navegador o bien utilizando tecnologías de complementos. Una de las más extendidas por su portabilidad era un firmador en Java utilizando applets, pero esta tecnología se está eliminando de los navegadores modernos y también siendo eliminada en futuras versiones de Java.

En la actualidad hay navegadores modernos como Edge que no disponen de ninguna forma de agregar complementos que permitan ejecutar código privilegiado y hasta la fecha no hay planes todavía para ello. Estos cambios fuerzan a utilizar formas más ingeniosas para resolver este problema de falta de interacción de sistemas de firma digital con los nuevos navegadores.

Afortunadamente existe una posible solución para comunicar sitios web con el hardware sin necesidad de complementos especiales en el navegador. La empresa que desarrolla y mantiene el proyecto DSS utiliza una técnica sencilla pero eficaz, mediante una aplicación de escritorio que ejecuta un servicio escuchando en un puerto en particular que tiene privilegios para acceder a los dispositivos de firma digital, los sitios web pueden comunicarse con este servicio local y enviarle la información que debe ser firmada y el resto del proceso se realiza en el lado de la web. Una de las aplicaciones existentes que utilizan esta técnica es software libre y se llama NexU, el cual se ha integrado en DSS a partir de la reciente versión 4.7.0, la cual ha decidido utlilizarla como reemplazo a los obsolescentes applets y JNLP.

Demostración de firma sin complementos de navegador

En el momento de escribir esto, he encontrado en línea una instalación de la WebApp de DSS 4.7 para poder probar NexU, que una vez descargado hay que ejecutar el jar que contiene el zip y recargar la página de la webapp, que detectará que se está ejecutando y el botón de formulario Install NexU cambiará a Submit. Para ejecutar el jar en GNU/Linux hay que tener instalado OpenJFX, que se explica en una entrada de blog previa. Para probarlo se puede desde una terminal mediante java -jar nexu.jar y manteniendo la terminal abierta. Para verificar que el servicio está ejecutándose correctamente se puede ingresar en el navegador en el sitio http://localhost:9776/nexu-info, donde debería aparecer un pequeño objeto JSON con la versión de la aplicación.

El problema del contenido mixto

El sitio web enlazado podría funcionar con HTTPS y el servicio local con HTTP, por lo que los navegadores modernos suelen bloquear esta comunicación. En Chromium aparece el icono de un escudo en la parte derecha de la barra de direcciones, donde haciendo clic se puede permitir la carga insegura y en Firefox aparece un candado verde con un triángulo gris con una exclamación, donde haciendo clic y a continuación en la parte derecha donde aparece un símbolo “>” se puede deshabilitar la carga insegura y finalmente el sitio web podrá acceder al servicio local.

A partir de las versiones 1.6.x de NexU se soporta HTTPS, una solución a este problema sería modificar la WebApp de DSS para que conecte a local por HTTPS y que exista un certificado para un host local, confiado e instalado en la máquina para que permita el acceso seguro a localhost y evitar el inconveniente del contenido mixto. La versión de NexU que sugiere DSS de momento es la 1.3, que no soporta HTTPS, por lo que debe descargarse la 1.6.2 o la 1.7 aparte y hacer los ajustes necesarios a DSS. En cualquier caso si bien la confianza SSL a localhost no se puede realizar con autoridades de certificación públicas, disponer de un nombre de host apuntando a 127.0.0.1 con una CA autofirmada, creada en la propia máquina, instalada y confiada y con ella firmando un certificado (para luego desechar la clave privada de la CA por seguridad) evita este problema. Otra opción sería usar un servidor seguro intermedio que se comunique con la aplicación de escritorio y el sitio web por backend, aunque esta opción también es relativamente compleja y requiere configuración a una dirección específica que haga conexión permanente desde la aplicación que accede a la tarjeta y mantener la comunicación abierta mientras esté el firmador en ejecución, pero esta solución requiere infraestructura adicional y la misma herramienta se alejaría de ser multipropósito sin previa actualización de la configuración.

Escenario ideal

Si bien esta solución es relativamente nueva y requiere algunos ajustes de configuración y previamente instalar la herramienta de acceso a la tarjeta, se perfila como una solución viable para poder realizar firma digital en la web de manera interoperable y multiplataforma. La posibilidad de que existieran actualizaciones a los instaladores de Firma Digital actuales del país contemplando la preinstalación de una herramienta de este estilo abriría la posibilidad de poder integrar esta solución en sistemas Windows, GNU/Linux y macOS y de que las instituciones adoptaran este mecanismo para solucionar el problema con los navegadores modernos.

4 comentarios en “Soluciones modernas para usar firma digital desde la web

  1. Anónimo:

    Vi alguien que lo hacia mas o menos asi (un jar ejecutandose local) y una conexion por WebSocket que es nativo de los navegadores.

    1. Francisco de la Peña:

      Así es, en el caso de Chrome siempre se pudo comunicar con dominios de terceros sin conexión HTTPS (contenido mixto) por websockets, pero Firefox bloquea este tráfico por considerarlo contenido mixto.
      Este artículo es de 2016, pero desde entonces, varios navegadores (Firefox, Chrome) permiten el tráfico mixto con localhost, no requiriendo en la actualidad (excepto Safari/WebKit) comunicarse sin tener que usar websockets o certificados, simplificando la implentación.
      Existen otros métodos que no requieren mayor instalación, ya sea parametrizando direcciones en un JNLP (Web Start) o instalando y registrando extensiones de fichero o protocolos para asociarlo a una aplicación, y en dicho protocolo o fichero recibir la ruta del fichero a descargar y un token/nonce para el fichero o sesón para restringir la descarga/subida no autorizada o para evitar ataques relacionados.

        1. Francisco de la Peña:

          En el caso de esa extensión requiere un componente “host” que se instala aparte, con el cual las extensiones web se comunican (native messaging), esto funciona en Firefox, Chrome y Edge, mientras que sugiere NPAPI para Internet Explorer (NPAPI ya no funciona en Firefox ni en Chome).
          El inconveniente de la modalidad de web extensions es que no ofrece ventajas con respecto a un instalador, ya que todavía lo requiere para instalar la aplicación host, sumado a que requiere instalar la extensión en el navegador. Con un instalador con un servicio local no requiere instalar extensiones, reduce la complejidad de la instalación y es compatible con todos los navegadores.
          Y para mixto HTTPS-HTTP funciona en localhost y/o 127.0.0.1 o ::1 con todos excepto safari, incluyendo Firefox 55 en adelante (para HTTP) y 70 (para websockets), sin necesidad de URLs de servicios complejas del lado del servidor, pudiéndose manejar desde XMLHttpRequest con JavaScript.
          Sin embargo, para Safari todavía bloquea ambos (http y websocket), es el único que no se ha adaptado a la especificación de la W3C, pero el bug tiene bastante actividad recientemente por peticiones de bastante gente: https://bugs.webkit.org/show_bug.cgi?id=171934

Deja un comentario

Tu dirección de correo electrónico no será publicada.