Cómo instalar Firma Digital de Costa Rica en openSUSE Leap 15.1, SLES 15 SP1 y SLE 15 SP1

Esta guía documenta cómo instalar el controlador de la tarjeta de Firma Digital de Costa Rica y la jerarquía de certificados del Banco Central (SINPE) y del MICITT en el sistema operativo openSUSE Leap 15.1, SUSE Linux Enterprise Server 15 SP1 y SUSE Linux Enterprise Desktop 15 SP1.

Las instrucciones están diseñadas para las distribuciones mencionadas previamente. Si se desea utilizar en distribuciones Fedora y Red Hat Enterprise Linux, existe la guía sobre cómo instalar Firma Digital de Costa Rica en Fedora, Red Hat Enterprise Linux 8 y CentOS 8. Para Debian y Ubuntu está la guía de cómo instalar Firma Digital de Costa Rica en Debian y Ubuntu.

Esta guía de instalación tiene los siguientes propósitos:

  • Configurar de la forma más sencilla y adecuada el sistema para que funcione con la mayor cantidad de programas.
  • Lograr que funcione para todos los usuarios del sistema, incluyendo los nuevos usuarios creados tras las instalación.
  • Aislar la librería de Firma Digital en una “caja de arena” (sandbox) para que funcione con múltiples usuarios del sistema simultáneamente (soluciona un defecto en la librería al crear ficheros temporales).

Instalación de las dependencias

  • Instalar el soporte CCID de PC/SC para que reconozca el protocolo usado por el lector de tarjetas Instalar IcedTea-Web para poder cargar algunos lanzadores que usan Java Web Start como por ejemplo el del sitio web de CrearEmpresa.go.cr (los navegadores ya no soportan applets Java, ya no es posible usar el del sitio web de la CCSS).
    sudo zypper install -y pcsc-ccid icedtea-web
    
    sudo systemctl restart pcscd.socket
    

Descarga del “instalador”

  • Descargar el “instalador” en el desplegable llamado “Usuarios Linux” en la página de descarga de instaladores del sitio web de Soporte Firma Digital de Costa Rica, introduciendo el número de serie de la tarjeta y aceptando las condiciones.
  • Descomprimir el archivo zip descargado con unzip, en el momento de escribir esta documentación se llama sfd_ClientesLinux_RPM64_Rev11.zip. Se creará una carpeta llamada Firma Digital. Se asume que el archivo zip se ha descargado en la carpeta Descargas:
    cd ~/Descargas/
    
    unzip sfd_ClientesLinux_RPM64_Rev11.zip
    

Instalación de los certificados

Es necesario agregar a la lista de confianza la jerarquía de certificados del SINPE y del MICITT. En teoría solamente sería necesario instalar los certificados raíz del MICITT pero en la práctica hay algunas aplicaciones que necesitan los certificados intermedios del SINPE para completar la cadena a la hora de validar. Para ello, un conjunto de comandos:

  • Copiar los certificados:
    sudo cp -p ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/Certificados/* /usr/share/pki/trust/anchors/
    

Instalación del módulo PKCS#11

Aunque hay un módulo en el directorio Librerías, no es la versión más reciente y tiene varios defectos de enlazado. La versión distribuida en el paquete PinTool es más reciente y funciona correctamente en todos los programas probados. En el siguiente proceso se extrae y se instala conservando la fecha original de la librería.

  • Instalar el módulo PKCS#11 privativo en /usr/lib64/:
    cd ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/PinTool/IDProtect\ PINTool\ 6.41.01/RPM/
    
    rpm2cpio idprotectclient-641.01-0.x86_64.rpm | cpio -dim ./usr/lib/x64-athena/libASEP11.so
    
    sudo cp -p usr/lib/x64-athena/libASEP11.so /usr/lib64/
    
    sudo mkdir -p /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib64/libASEP11.so /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib64/libASEP11.so /usr/lib/
    
  • Permitir temporalmente al usuario local cargar aplicaciones gráficas con sudo (kate o gedit, según se use KDE o GNOME):
    export SUDO_EDITOR=kate
    
  • Crear el fichero /etc/Athena/IDPClientDB.xml y abrirlo para edición:
    sudo mkdir /etc/Athena/
    
    sudoedit /etc/Athena/IDPClientDB.xml
    
  • En la ventana del editor de textos, pegar el siguiente texto, guardar y cerrar el editor:
    <?xml version="1.0" encoding="utf-8" ?>
    <IDProtect>
     <TokenLibs>
      <IDProtect>
       <Cards>
        <IDProtectXF>
         <ATR type='hexBinary'>3BDC00FF8091FE1FC38073C821106600000000000000</ATR>
         <ATRMask type='hexBinary'>FFFF00FFF0FFFFFFFFFFFFFFFFF0FF00000000000000</ATRMask>
        </IDProtectXF>
       </Cards>
      </IDProtect>
     </TokenLibs>
    </IDProtect>
    
  • Crear un fichero llamado /usr/share/p11-kit/modules/firma-digital.module y abrirlo para edición:
    sudoedit /usr/share/p11-kit/modules/firma-digital.module
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    remote: |bwrap --unshare-all --dir /tmp --ro-bind /etc/Athena /etc/Athena --proc /proc --dev /dev --ro-bind /usr /usr --ro-bind /lib64 /lib64 --ro-bind /var/run/pcscd /var/run/pcscd p11-kit remote /usr/lib64/libASEP11.so
    
  • Crear un fichero llamado /usr/sbin/update-p11-kit-nss-proxy y abrirlo para edición:
    sudoedit /usr/sbin/update-p11-kit-nss-proxy
    
  • En la ventana del editor de textos, pegar el siguiente texto, guardar y cerrar el editor:
    #!/bin/sh
    
    if ! [ -L /usr/lib64/libnssckbi.so ]
    then
        echo libnssckbi.so is not a symbolic link. Backing up...
        mv -f /usr/lib64/libnssckbi.so /usr/lib64/libnssckbi.so.bak
    fi
    
    if ! [ "$(readlink /usr/lib64/libnssckbi.so)" = p11-kit-proxy.so ]
    then
        echo libnssckbi.so is not pointing to p11-kit-proxy.so. Fixing...
        ln -sf p11-kit-proxy.so /usr/lib64/libnssckbi.so
    fi
    
  • Agregar el atributo de ejecutable al script:
    sudo chmod +x /usr/sbin/update-p11-kit-nss-proxy
    
  • Crear un fichero llamado /etc/systemd/system/p11-kit-nss-proxy.service y abrirlo para edición:
    sudoedit /etc/systemd/system/p11-kit-nss-proxy.service 
    
  • En la ventana del editor de textos, pegar el siguiente texto, guardar y cerrar el editor:
    [Unit]
    Description=Update libnssckbi.so symbolic link
    Wants=local-fs.target
    
    [Service]
    Type=oneshot
    ExecStart=/usr/sbin/update-p11-kit-nss-proxy
    
    [Install]
    WantedBy=default.target
    
  • Crear un fichero llamado /etc/systemd/system/p11-kit-nss-proxy.path y abrirlo para edición:
    sudoedit /etc/systemd/system/p11-kit-nss-proxy.path
    
  • En la ventana del editor de textos, pegar el siguiente texto, guardar y cerrar el editor:
    [Unit]
    Description=Watch for changes in libnssckbi.so
    After=local-fs.target
    
    [Path]
    Unit=p11-kit-nss-proxy.service
    PathChanged=/usr/lib64/libnssckbi.so
    
    [Install]
    WantedBy=default.target
    
  • Activar el servicio para que se ejecute al detectar cambios en la ruta:
    sudo systemctl enable --now p11-kit-nss-proxy.path
    
    sudo touch /usr/lib64/libnssckbi.so
    

Eso es todo. Es necesario reiniciar Firefox y cualquier otra aplicación que use certificados para que se apliquen los cambios.

Quizás resulte interesante utilizar la herramienta Firmador, software libre para firmar documentos.

Firma PDF avanzada: cuando LTV no es lo mismo que LTV

En Costa Rica, la “Política de Formatos Oficiales de los Documentos Electrónicos Firmados Digitalmente”, versión 1.0, indica en su punto 5, “Especificación de los Formatos Oficiales”, los formatos avanzados y configuración de niveles de los documentos firmados. Para el caso del formato PDF, indica que se basa en la norma técnica “ETSI TS 102 778”, indicado textualmente como “PAdES Long Term (PAdES LTV)”. Lo que hay entre paréntesis se refiere al perfil PAdES-LTV, que se especifica en la parte 4 de esa norma de la ETSI (TS 102 778-4).

LTV puede resultar engañoso. Es un acrónimo que significa Long Term Validation o validación a largo plazo. Sin embargo, hay dos interpretaciones: la de los estándares de la ETSI y la de Adobe. Y esto es un problema.

Quienes hayan utilizado Adobe Acrobat Reader DC para validar firmas digitales habrán visto en el panel de firmas el texto “Activada para LTV” o “No activada para LTV y expirará el xx/xx/xxxx”. De hecho, en las guías oficiales de validación en los sitios de mifirmadigital.co.cr o incluso en las de soportefirmadigital.com indican que este es el mecanismo para indicar si una firma tiene el nivel necesario, aunque discrepo y por esa razón escribo esta entrada de blog tratando de explicar por qué.

¿Qué es LTV, según Adobe?

No hay una definición oficial o documentada por parte de Adobe. Algunos empleados de esa empresa han indicado su opinión sobre qué entienden ellos por LTV para que su validador lo muestre. Una respuesta en StackOverflow sobre el significado de activación LTV detalla que lo que interpreta Adobe sobre activación LTV no solo no es lo mismo que PAdES-LTV sino que su validador Adobe Acrobat Reader DC puede interpretar documentos que cumplan perfectamente la especificación PAdES-LTV como que no están activados como LTV. No obstante, la herramienta Firmador hace uso de la librería implementación de referencia de la Unión Europea y en las pruebas realizadas con el validador de Adobe Acrobat Reader DC en sus últimas versiones, habría mejorado para ser más compatible con PAdES e incluso tiene un apartado algo escondido donde indica el nivel de firma PAdES Baseline, pero esto no se refleja en las guías de verificación de firma del país porque es un poco más complicado encontrarlo.

A su vez, validadores que no son de Adobe, como es el caso de la herramienta Firmador, pueden indicar que un documento no cumple con el nivel PAdES-LTV y sin embargo aparecer como “activada para LTV” en Adobe Acrobat Reader DC.

Si en Adobe Acrobat Reader DC se instalan los certificados intermedios en la lista de certificados confiados (tal y como sugiere la guía oficial de instalación de certificados para este programa), el documento puede mostrar para un documento PDF que su firma está activada para LTV, aunque el documento no contenga los certificados intermedios tal y como indica la especificación PAdES requerido para el nivel PAdES-LTV o también como lo menciona explícitamente la normativa nacional. Ni siquiera es necesario que el documento tenga un sello de tiempo a nivel firma, por lo que podría incluso ser un nivel tipo PAdES-B y aun así mostraría que está activada para LTV en Adobe Acrobat Reader DC. Si se instalara solamente el certificado raíz nacional y no los intermedios (como sería lo ideal) y se desconecta de Internet, la validación en Adobe Acrobat Reader DC probablemente fracasará, al no poder verificar CRL y OCSP en línea y también fallará al no poder descargar desde las URLs especificadas en la extensión Authority Information Access (AIA) los certificados intermedios faltantes. Los documentos firmados con la herramienta Firmador sí pueden validarse sin conexión a Internet, como otra demostración de que incluyen toda la información necesaria para su validación.

¿Qué es LTV, según ETSI? (PAdES-LTV)

PAdES-LTV es un nivel de perfil que está especificado en el el documento ETSI TS 102 778-4. De toda la norma, hay un punto especialmente importante que no contempla Adobe pero que sí está en el estándar y es necesario para cumplir con él. Sin embargo, pocos firmadores en el país realizan este procedimiento correctamente: el PDF firmado requiere que incluya al menos un sello de tiempo a nivel documento para cumplir con el nivel PAdES-LTV.

El sello de tiempo a nivel documento no es lo mismo que el sello de tiempo que llevan las firmas. Este sello cubre todo el documento, por lo que también cubre la información de revocación, para demostrar desde el momento que tiene el sello, la información no solo no se había modificado y por tanto que la información de validación de la firma (CRL y OCSP), sino que esta información existía así en ese momento, así como que los certificados eran vigentes y que todo ello era válido. Esto permite que aunque los certificados venzan, esta información siga siendo válida porque en su momento lo era. Esto está claramente especificado en la parte 4 de la norma, concretamente en el punto 4.2 párrafo b) y además indica en el anexo B que incluso en el nivel de perfil equivalente a CAdES-X-L debe llevar un sello de tiempo a nivel documento en los PDF.

Si un documento no incluye un sello de tiempo a nivel documento, cuando los certificados venzan, aunque la información fuera válida en su momento, el documento no podrá ampliar su nivel de firma a PAdES-LTV porque debería haberse añadido este sello de tiempo antes de que vencieran. No se resuelve intentando agregar este sello de tiempo cuando ya están vencidos. Un ejemplo práctico de este caso se puede comprobar con el validador de la herramienta Firmador y abriendo el documento PDF de la política de formatos oficiales. Aparecerá un error indicando que el estado de validación es indeterminado con el código de error interno “NO_POE”. PoE es Proof of Existence o prueba de existencia, que está especificado en nuevas normas técnicas de ETSI que indican formalmente qué significa el sello de tiempo a nivel documento y sus implicaciones. Lo que indica esta definición es que no hay manera de demostrar si los certificados intermedios eran válidos antes de que vencieran, en el hipotético caso de que pudiera comprometerse la seguridad y emitir nuevos certificados equivalentes para la infraestructura. En Costa Rica no hay una definición de validación basada en especificaciones técnicas que se publicaron después, aunque el documento de formato oficial indica claramente en el punto (5.2.2) un conjunto de atributos que son comunes a todos los perfiles AdES long term y que en el caso de Adobe en su validador de PDF puede indicar “activado para LTV” incluso aunque le falten los atributos de sello de tiempo, rutas de certificación e información de revocación dentro del documento.

Firmador, LTV y LTA

Los problemas con la confusión y acceso en aspectos de Firma Digital, más específicamente en documentos PDF, además de la falta de un software libre con código fuente de acceso público fueron las motivaciones por las que se creó la herramienta Firmador: disponer de una herramienta que firme y valide ajustándose lo mejor posible a los estándares y a la normativa de Costa Rica.

Tal y como indica la política de formato oficial del país, las implementaciones a medida pueden utilizar el perfil Baseline. Este perfil, especificado en la norma técnica TS 103 172 de ETSI, es bastante similar al anterior, aunque simplifica los niveles con ciertas equivalencias, por ejemplo el nivel B incorpora BES y EPES, el nivel X-L equivale a LT y el nivel A o LTV equivale LTA. Por este motivo, la herramienta validador puede mostrar PAdES-BASELINE-LTA en lugar de PAdES-LTV, ya que utiliza los nombres simplificados del nuevo estándar, aunque a efectos prácticos se trate prácticamente de lo mismo.

La Unión Europea financió la creación de una librería como implementación de referencia que permitiera firmar documentos llamada Digital Signature Services (no confundir con el estándar de la OASIS), que permite firmar con los formatos estándar XAdES, CAdES y PAdES, parte de los cuales son los estándares en Costa Rica, así como la validación, basada en nuevos estándares no contemplados por la normativa nacional hasta la fecha. Puesto que todo software puede contener errores, es conveniente utilizar siempre la versión más reciente de la librería. Por ejemplo, para la versión 5.4 de esta librería implementaron una opción para poder incluir sellos de tiempo de jerarquías no confiadas, ya que el servidor de la TSA del SINPE está firmado con la jerarquía de certificados nacional, entonces al agregar el nivel LT no se estaban incluyendo los certificados intermedios de la TSA y al realizar la validación LT sin conexión a Internet fallaba al no detectar los certificados intermedios que se utilizaban para el proceso de validación OCSP. También corrigen diversas vulnerabilidades, como las de tipo XXE.

Pueda o no gustar desarrollar en Java, que es con el lenguaje con el que se desarrolla esta implementación de referencia, es probablemente la mejor apuesta para trabajar con estos formatos, ya que simplifica enormemente el proceso de firma, requiriendo unas pocas líneas de código para firmar un documento, a diferencia de librerías como iText, con las que además se pueden agregar errores con facilidad con respecto a la especificación del formato.

Compatibilidad con las implementaciones

En el momento de escribir este artículo, el validador de documentos del Poder Judicial, bastante utilizado para presentar recursos en línea, no funciona correctamente cuando el documento incluye el sello de tiempo a nivel documento. Este problema se ha notificado al departamento correspondiente y se está a la espera de que se confirme una posible corrección.

Muchos firmadores no incluyen este sello de tiempo pero debería agregarse eventualmente por los motivos indicados. Si todavía son válidos, con la herramienta Firmador puede realizarse este procedimiento, no es necesario disponer de dispositivo de Firma Digital. Es conveniente que para un archivado longevo de documentos este proceso sea realizado por todas aquellas personas que almacenen documentos firmados.

La herramienta Firmador es capaz de firmar documentos sin conexión a Internet y agregar en otra ocasión todos los atributos necesarios sin intervención del firmante sino que lo puede hacer otra persona como puede ser quien reciba los documentos (receptor), tal y como indican los puntos 5.2.1 y 5.2.3 de la especificación del formato oficial de Costa Rica. Sin embargo, algunos validadores no reconocen bien la firma ampliada/extendida desde el nivel PAdES B-B a B-LTA posteriormente (lo que en el documento del formato oficial se refiere a “incluir los atributos” de niveles superiores), ya que agregar el sello de tiempo a la firma no se representa de la misma manera a como lo entienden los validadores de iText o el validador de Adobe, aunque este último sí reconocerá la inclusión de los atributos de la firma como “activada para LTV”.

Existen numerosos firmadores en el país que no agregan los atributos con los nombres adecuados y conforme al estándar, provocando que el validador que usa Firmador muestre la firma como PKCS7-T o similar en lugar de PAdES-T o superior. Aunque la firma básica sea válida en estos casos, no es conforme al estándar que rige. En estos casos en los que la firma no es conforme al estándar y no se resuelve extendiéndola, o en otros supuestos como de certificados vencidos y no extendida con sello de tiempo a nivel documento, la única solución pasa por eliminar la firma del documento y crear una nueva. Quizás en el caso en el que una especificación local relajara la exigencia sobre el formato de firma, un validador podría ser menos estricto por motivos de compatibilidad con documentos heredados de una herramienta que no se adaptó tan bien a los estándares en el pasado.

Conclusiones y recomendaciones

Es un hecho que debido a la evolución de las implementaciones del software y de los estándares se han ido acumulando dificultades en cómo deben firmarse los documentos de forma correcta y adaptada a los estándares. En los casos en que el software por ejemplo no indicaba si el LTV se refería al estándar PAdES y la falta de herramientas años atrás de mecanismos para validar si se estaba realizando correctamente causa estas asperezas, suponiendo que haya que realizar una mejora continua para actualizar los procesos que hagan uso de Firma Digital y tener conciencia de ello por parte de las personas encargadas en lo personal y en instituciones públicas y privadas.

El documento actual de la especificación del formato oficial está escrito cuidadosamente y de manera más sencilla posible para el entendimiento de personas no capacitadas técnicamente sobre cómo deben ser firmados los documentos, los tipos y especificaciones técnicas que deben cumplir y qué deben contener (atributos), así como lo más genérico posible para poder interpretarse en el futuro de forma compatible. Esto fue en 2013, cuando todavía en la Unión Europea no se había creado el estándar oficial eIDAS, que releva a las especificaciones previas, por ejemplo en el caso de PAdES las normas técnicas ETSI TS 102 778 (PAdES) y ETSI TS 103 172 (PAdES perfil baseline) se actualizan con el estándar europeo ETSI EN 319 142, publicado por primera vez en 2015 (donde se agrega el concepto de prueba de existencia). También apareció el primer estándar europeo para validar documentos AdES, el ETSI EN 319 102, basado en la norma técnica ETSI TS 119 102 que se sigue actualizando con enmiendas que posteriormente actualizarán el estándar.

Sería conveniente que ya que hoy en día se dispone de estándares y software de validación mejor regulado en la Unión Europea, actualizar la normativa costarricense para adoptar selectivamente lo que permita de forma equivalente para disponer de un mecanismo de validación más sólido. El software de implementación de referencia (Digital Signature Services) dispone de mecanismos ajustables para configurar de forma afinada qué puntos de la validación son requeridos u opcionales para poder configurarse de la forma más conveniente y adaptado a las necesidades nacionales.

Ejemplos de adaptación al sistema de validación ya existe en otros países fuera de la Unión Europea, como es el caso del Perú, que ya dispone de un sistema de validación nacional centralizado. Mientras no existan mecanismos precisos en Costa Rica, la herramienta Firmador utiliza los parámetros más predeterminados posibles (los utilizados en la Unión Europea) en el validador integrado, hasta que algún día, en caso de existir, pueda ajustarse a una normativa más precisa y local.

El motivo de regular la validación de forma más precisa permitiría disponer de mecanismos eficaces y más seguros para garantizar la seguridad y fiabilidad de los documentos firmados digitalmente, como es el caso de los documentos a largo plazo (el caso de los LTV aquí tratado), así como de cómo manejar la validación adecuadamente en la jerarquía nacional; por ejemplo si llega el caso en que nuevas autoridades de registro (RAs, certificados intermedios como el del BCCR) y se incorporasen al conjunto de jerarquías y documentos firmados bajo estas para validar. Sobre los aspectos de certificados intermedios y la forma de distribuirlos hay algunos aspectos que podrían mejorar también, pero eso será para otro artículo de blog.

La herramienta Firmador tiene previsto mejorar el reporte de validación de documentos para hacerlo más intuitivo y detallado. También está previsto este año publicar un validador web para quien quiera validar documentos sin necesidad de descargar software y que funcione en cualquier dispositivo que tenga conexión a Internet y un navegador web. Como en el caso de Firmador, se distribuirá como software libre, estando el código fuente del validador web para que cualquier persona pueda instalarlo en sus servidores y/o adaptarlo a sus necesidades.

Firmador 1.4.0 publicado

Se acaba de publicar la nueva versión de este firmador digital de documentos para Costa Rica. La principal novedad es la implementación de firma visible en documentos PDF.

La firma visible es como se conoce popularmente a la apariencia de la firma. Se trata una representación visual dentro el documento como las firmas manuscritas creadas por personas y que están vinculadas a una firma digital. Esta representación visual está recogida en la especificación técnica que se utiliza en documentos PDF firmados digitalmente acorde con la política de formato oficial de Costa Rica.

El propósito de esta representación visual de las firmas es orientar a las personas que reciban un documento, sobre todo a las que no han recibido capacitación, para tener información dentro del documento que indica que contiene una firma digital. Esta representación muestra el nombre de la persona que firma, la fecha declarada de la firma y otros atributos.

La implementación se ha realizado gracias a la versión en desarrollo de la librería DSS, que es la implementación de referencia que permite aplicar firma AdES, financiada por la Comisión Europea. A partir de la versión 5.5 implementan una característica que permite utilizar texto plano, permitiendo que la firma sea más accesible mediante lectores de pantalla y que el tamaño del fichero no sea significativamente mayor. En versiones anteriores se generaba una imagen de píxeles a partir del texto.

Para ubicar la firma visible, tan solo hay que abrir un documento PDF a firmar para luego, en la pestaña Firmar, arrastrar el rectángulo “Firma visible” a la ubicación adecuada de la página deseada y finalmente hacer clic sobre el botón “Firmar documento”.

Firmador es software libre y se puede descargar desde el sitio web firmador.app para GNU/Linux, macOS y Windows.

Sitios web rápidos sin sacrificar seguridad

En estas fechas, ya son mayoría los sitios web que utilizan conexión segura con TLS, existiendo certificados gratuitos como los de Let’s Encrypt y los de Buypass.

Sin embargo, la seguridad de los sitios es algo más que proteger la comunicación entre el cliente y el servidor. El mantenimiento preventivo del software que se utiliza para la gestión del contenido del sitio debe ser riguroso, ya que es habitual descubrir vulnerabilidades de vez en cuando.

De estas vulnerabilidades, hay unas en particular que suelen suceder con mucha frecuencia pero no se le da tanta importancia como pueden ser las inyecciones de SQL. Lograr manipular el contenido de un sitio a partir de otro para extraer información o manipular formularios pueden ser dañinos si se realizan correctamente, como pueden ser los de tipo XSS y CSRF.

Por ejemplo, el código JavaScript adicional que viene incluido con el marco de trabajo Bootstrap ha tenido numerosas correcciones para mitigar ataques XSS en los últimos años, a pesar de que la cantidad de JavaScript que contiene es relativamente pequeña. Si miramos otras librerías JavaScript más grandes, el riesgo es posiblemente mayor.

Afortunadamente existen mecanismos para mitigar este tipo de ataques, sin embargo no son todavía muchos sitios web los que aplican estas medidas, ya que puede requerir modificar gran cantidad de código del lado del cliente (HTML, CSS y JavaScript) para que sea compatible con este tipo de prevención de ataques. Los navegadores web modernos permiten evitarlo, pero hay que indicarlo explícitamente por motivos de compatibilidad con el sitio.

Existen diversas propuestas para mitigar los ataques XSS mediante cabeceras de seguridad mediante protocolo HTTP. Por ejemplo, el observatorio web de Mozilla permite analizar qué cabeceras se pueden utilizar y si están utilizándose para mitigar potenciales ataques. Una de las más importantes es Content Security Policy, que puede evitar inyecciones de scripts si estos no vienen definidos en el documento previamente. Es decir, se puede evitar inyectar por ejemplo JavaScript si no viene de una fuente autorizada. Hay unas cuantas cabeceras más que permiten otro tipo de técnicas como clickjacking y otro tipo de ataques. En ese sitio web viene una descripción de cada uno.

Otra medida que puede emplearse en los navegadores modernos es el uso de cookies tipo SameSite. Por ejemplo, si se utilizan cookies de sesión, a partir de PHP 7.3 se puede definir que estas sean de este tipo para mitigar ataques CSRF en formularios sin necesidad de tener que rotar un token como era la mitigación del problema hasta ahora.

Es conveniente mencionar que algunas de estas cabeceras tienen bastantes años de existir, por lo que no debería ser un pretexto no implementarlas y hacer uso de tecnología web que no arrastre demasiada deuda técnica como para que impida hacer uso de las mismas, sobre todo en nuevos proyectos.

La velocidad no se sacrifica

Puede parecer que utilizar medidas como esta impediría aprovechar las supuestas ventajas de emplear redes de entrega de contenidos (CDN), que al menos parece que permiten acelerar el tiempo de carga.

En las cabeceras que cargan scripts que son de otros dominios, puede resultar un riesgo, en caso de que servicios de terceros se comprometan, de servir código que pudiera ser maligno. Y como no es la primera vez que sucede, existen soluciones como agregar una suma de comprobación (hash) o agregar nonces para evitar cargar scripts que hayan sido modificados. Tener que manejar estos aspectos podría complicar todavía más el desarrollo web.

Pero sobre el uso de servicios de terceros y CDN en general, habría que reflexionar por qué comenzaron a utilizarse. Hasta hace unos años, el protocolo HTTP/1.1 tenía limitaciones para cargar múltiples recursos a la vez, ya que cada petición utilizaba una conexión TCP. Aunque el HTTP pipelining permitió mitigar el problema, no era la mejor solución porque también estaba limitada a un número de conexiones TCP. Sin embargo, hoy en día hay una mucho mejor, especialmente desde el momento en el que las conexiones seguras entraron en escena.

Muchas personas pueden reconocen que tener que usar conexión HTTPS segura con TLS (HTTPS) es para evitar que aparezcan mensajes en los navegadores que su formulario o su dirección es insegura, pero HTTPS también es necesario para utilizar cada vez más características del navegador, como por ejemplo acceso a la geolocalización o incluso algunos dominios de primer nivel como los .app o .dev que cualquiera puede registrar, el navegador exige comunicación HTTPS de forma estricta.

Existe una nueva especificación llamada HTTP/2 que permite resolver de golpe todas las limitaciones de HTTP/1.1. Se utiliza una única conexión TCP para la transmisión de los datos. Hace unos cuantos años que servidores web como Apache HTTPd soportan esta tecnología. La mayoría de navegadores modernos han decidido que para poder disfrutar de HTTP/2 se requiere HTTPS.

Volviendo al tema de los CDN, una de las características de estos servicios es que han sido de los primeros en ofrecer HTTP/2 pero por una buena razón: el contenido se sirve mucho más rápido y por tanto aparenta competir mejor que si se sirve desde el propio sitio web, ya que todavía hay mucha gente que no ha considerado en servir sus sitios web con HTTP/2. En tiempos de HTTP/1.1 mejoraban el rendimiento, incluso sin que estos usaran HTTP/2, pero ya no es así.

Si un sitio web decide usar HTTP/2 para servir la información, podría incluso ser más rápido que utilizando los CDN gracias a esto. El motivo es porque los CDN por HTTP/2 requieren usar HTTPS, lo que supone una negociación TLS completa, aparte del tiempo de resolución de cada uno de los nombres de dominio. Aunque existen técnicas como DNS prefecthing, el conjunto de negociaciones va a ser más costoso que realizarlo desde un mismo sitio, salvo excepciones en sitios web que sean realmente muy grandes donde distribuir la carga merezca la pena, aunque sea por unos pocos milisegundos. Si a esto le sumamos el tiempo ahorrado en configurar la seguridad del sitio para mitigar ataques, creo que es un aspecto relevante a tener en cuenta.

Otra de las características de HTTP/2 además de dejar bastante obsoletos los CDN, también deja obsoletos los empaquetadores de recursos (JavaScript, CSS). Estos empaquetadores, como pueden ser Webpack y otros, complican y ralentizan el despliegue, además de tener que administrar una configuración monstruosa y también requiere trabajo adicional de descarga y de velocidad si hay que depurar errores. Además, evitan que el cache de los navegadores sea útil si hay cambios en los mismos, ya que habría que volver a descargar un enorme paquete si cambia una sola línea de un script, mientras que disponibles de forma individual no lo requeriría.

HTTP/2 permite también utilizar un mecanismo llamado server PUSH para enviar al navegador contenidos antes de que se los pida. Esto permite acelerar en algunos sitios web el tiempo carga de forma muy significativa. Con HTTP/1.1 lo más parecido era el preload en etiquetas link, pero tenía que descargarse primero el documento HTML para poder saber que se tenían que descargar, perdiendo un ciclo valioso que se multiplica en conexiones con latencia elevada. En el caso de Costa Rica hay mucho tráfico que viene desde fuera incluso tráfico local rebotado con latencia significativa, por lo que reducir los round trips puede reducir varias veces el tiempo de carga en estos casos. Con PUSH puede enviarse la información a Early Hints, que se sirven incluso antes de comenzar a transmitir el documento solicitado (antes del HTTP 200).

Es conveniente servir con compresión (aunque teniendo cuidado con ataques tipo CRIME). Mucha gente utiliza solamente compresión GZIP, sin embargo también existe Brotli, que permite ahorrar un porcentaje significativo de tráfico en las descargas y por tanto cargar más rápidamente. Otras formas de ahorro de ancho de banda en la conexión segura inicial es utilizar certificados de curva elíptica (ECC), soportado por todos los navegadores modernos y permitiendo descargar certificados más pequeños, además pueden aliviar la carga del servidor al cifrar la información sin necesidad de aceleración por hardware. Utilizar versiones del protocolo TLS más modernas (1.3) también permiten utilizar cifrados más eficientes y seguros. Por compatibilidad con sistemas antiguos se pueden ofrecer ambos certificados (ECC + RSA).

Otro aspecto que implica una dependencia de terceros es la consulta de estado de revocación del certificado TLS. Esta consulta se realiza a los servidores OCSP de la autoridad de certificación, que podría tener momentos en los que funcionara más lento de lo habitual (como le podría suceder a un CDN), además de que implicaría una consulta adicional. Adicionalmente, las autoridades de certificación sabrían cuánto tráfico tendría tu sitio web y de dónde provienen sus visitantes, por lo que también, como en el caso de los CDN, tiene implicaciones de privacidad. Para mitigarlo existe el grapado OCSP, que es un mecanismo por el cual el estado de revocación se envía directamente desde el sitio web sin depender del tercero. Este grapado es un mecanismo que queda guardado en memoria cache del servidor web y contiene una consulta firmada digitalmente con sello de tiempo que garantiza que el estado de revocación del certificado era válido, teniendo un tiempo de vida relativamente corto, por lo que es el servidor web el que va renovando y cacheando estas consultas. Con esto se mejora también muy ligeramente el tiempo de negociación de la conexión HTTPS.

Recomendaciones

En resumen, algunas recomendaciones para el desarrollo web moderno, logrando seguridad, velocidad y un desarrollo más eficiente:

  • No utilizar servicios CDN si no es necesario.
  • Utilizar cabeceras de seguridad (CSP, HSTS y demás).
  • Utilizar grapado OCSP.
  • Utilizar cookies SameSite (si el sitio usa cookies).
  • Utilizar HTTP/2.
  • Utilizar server PUSH (si es con Early Hints, mejor).
  • Utilizar compresión Brotli.
  • Utilizar TLS 1.3.
  • Utilizar certificados ECC (o dual ECC + RSA).

Este sitio web hace uso de todas estas características y probablemente se note en el tiempo inicial de carga, tanto en computadoras de escritorio como en dispositivos móviles en redes fijas y celulares. Recomiendo utilizar Apache HTTPd porque es el primer servidor HTTP en cumplir al 100% con la especificación HTTP/2 (y no, no es más lento que nginx, esto lo explicaré en otro artículo de blog).

Follow this quality checklist before an audit

At Zeppelin we help protect the core infrastructure of open and decentralized applications. I'm part of the Research team, which is in charge of conducting security audits. We review tons of lines of code written by very smart developers for projects that will shake the foundations of our society.

Finding security vulnerabilities in this futuristic cypherpunk environment is super challenging and fun, but we have already covered those topics elsewhere. I think that security actually starts in a pretty boring and traditional place, full of the wisdom that our elders have collected through millennia of developing software in community. Standing on their shoulders, I want to share our checklist for basic quality measures that your next awesome project should consider before you hand it over for an external audit.

✔️ Choose a free software license

Closed code is inherently insecure. If people who use your project can't inspect it, study it, hack it, and experiment on it, there's no way it can be trusted. If you hold abusive control over your users, nothing prevents you (or anyone more powerful than you) from making them vulnerable.

Take a look at the Free Software Definition, and begin with choosing the license that best suits your needs.

This is a good moment to introduce our first wise elder! Richard Stallman 😜, who hacked copyright laws, started the free software movement, and wrote the above definition.

Richard Stallman

Richard Stallman in costume as St. IGNUcius (Monastir, Tunisia, 2012. Image taken from Wikipedia)

✔️ Build your core team of maintainers

When your project succeeds, hundreds of external contributors will surely be supporting it. But in order to get to that point, you'll need to bootstrap with a strong and diverse team of core maintainers. They'll take care of the bulk of the work, the fun and the boring parts, proposing and reviewing the code of your shared project. Together, you all need to have strong knowledge of all points on this checklist. Look not only for technical knowledge, but also for a knack for cat-herding and a healthy work style—because, well, things will get complicated.

Pay attention to your bus factor: make sure your team members are sharing their expertise, the lessons learned, and their responsibilities, while at the same time constantly mentoring new people that could potentially join the core team.

And somebody will have to lead and orchestrate in order to get value out of the eternal tendency toward chaos. Let me introduce you to our second magician, Camille Fournier, who wrote THE book on technical management, The Manager's Path.

Camille Fournier

Camille Fournier (Image taken from her website)

✔️ Write clean code

The only valid measurement of code quality is WTFs per minute. This point must be simple. If things get overly complicated or weird, you're doing it wrong. Go for a walk and try again with fresh eyes.

But don't get me wrong: no interesting software project is simple. Add the complexity dimensions of decentralization, transparency, cryptography, and all these shiny ideas that are keeping us so busy these days. It's complicated by design. But with the correct abstractions, a well thought-out model, and proper encapsulation, you can start building the bank-killer app one line at a time. And each of those lines must be clean and readable.

I'm not a spectacular programmer, I was just lucky to find Uncle Bob Martin's book Clean Code at the right moment and to have read a never-ending stream of very, very ugly code.

Robert C. Martin

Robert Cecil Martin (Image taken from Wikipedia)

Once all core maintainers reach common ground on this topic, you should enforce a consistent code style by running a linter on every new line of code that's added. The particular rules aren't as important as following them strictly is, but if you can sacrifice your peculiar preferences to be consistent with the rest of the world, your contributors will appreciate it a lot.

I also practice slow-food... er, slow programming. Take your time, enjoy the journey to mastering this craft, and when you've built something you can proudly set free, let the masses read it and judge it.

✔️ Write unit tests

Write unit tests. Tons of them. 100% coverage. This might sound extreme, but hey, your code is now playing directly with somebody else's money. If you forget, or just get lazy and don't write a test for that super obvious line of code, you might be leaving an open door for an exploit later in the game that will make your project crash, and all this magic internet money will disappear in no time. It has happened.

I feel immediately more secure when I do test-driven development. At least give an honest try to writing the tests first, and get into a cycle of red-green-refactor. There are other techniques that can achieve the same result, but I suggest starting there and then deviating if you find good reasons to do so. Never worked this way? Read Test Driven Development: By Example by Kent Beck. It's a quick read that will help you avoid the temptation of just jumping into code without thinking it through.

Then, even if you design for testability, you'll find many scenarios that are hard to test. Gerard Meszaros provides all the answers in xUnit Test Patterns. This book is huge, so I recommend choosing a designated test expert on your team.

Kent Beck Gerard Meszaros

Left: Kent Beck speaking in 2001 (Image taken from Wikipedia) Right: Gerard Meszaros (Image taken from Twitter)

Finally, make sure to run your unit tests on every single pull request, and make sure they're all green before merging the changes. In addition, you can set up a test coverage report to ensure that test coverage never goes down.

✔️ Test early, test often, test agile

Now that you have your first layer of tests covered with tons of unit tests, what comes next is...more tests! You need to test the integration between all of your components, then go one level higher to test your application from the point of view of a real user, and then go even higher to test the interactions with other systems end-to-end.

To me, this is the biggest challenge, and designing a good process that keeps many bugs out of your system can be as difficult as designing the system itself. Iterate, automate as much as possible, share the load of manual testing...and let your community help.

We'll talk later about community, but I think this is the reason for publishing your code as early as possible: you can get help from early adopters and enthusiasts to validate your system, not only for correctness but also to verify that you're focusing on the right user stories and that you're tackling a real problem with a user-friendly solution.

A lot has been written about iterative development processes that deliver functionalities in progressive sprints and milestones. I found Mike Cohn's Succeeding with Agile: Software Development Using Scrum a good place to start, but keep in mind that any methodology will have to be adjusted to your team, your users, and your context. There are a lot fewer resources focused on the quality and testing part; that's why I was so happy when I read Agile Testing by Lisa Crispin and Janet Gregory, which is full of good ideas and advice. But let me stress again: nothing you read will perfectly fit your project, so take your time to design the testing process with as much love and care as you use when designing the system's architecture.

Mike Cohn Lisa Crispin and Janet Gregory

Left: Mike Cohn in 2013 (Image taken from Wikipedia) Right: Right: Lisa Crispin and Janet Gregory (Image taken from their website)

While there's still some debate about the perfect moment for auditing a project (i.e, before or after the code is published), I think audits should be performed when there's a release candidate ready to be deployed to mainnet, after you have performed extensive alpha and beta testing. I see room for auditing before the code has been published, but in this case, the audit would be more related to checking that the development process will lead to a high-quality, properly tested release candidate and validating the bases of your project than to performing a deep and thorough inspection of the codebase.

However, this doesn’t mean that you have to wait until the end of a long development phase to prepare for a release and audit. Once you start writing and testing clean code in incremental iterations, it becomes easier to think about your complex system. Many smaller independent parts will start to pop up, which can be extracted, generalized, and packaged for reuse, reducing anxiety for developers and auditors. These packages are the focus of ZeppelinOS for this year, to know more take a look at the State of EVM Packages.

✔️ Write documentation

This is my least favorite part, by far. So let's keep it simple, starting at the beginning: the README, the most important file of your repository. And yet, it's usually either empty or bloated, outdated, and ugly. Ideally, as it's the first thing developers and potential contributors will read, it should work as a clear, straightforward index of your project.

It's best not to get creative here. Just follow this simple specification that works for all cases, proposed by Richard Littauer in Standard Readme. Do not forget to include a specific section in the main README that states how people should disclose any security vulnerabilities found in your project.

Richard Littauer

Richard Littauer (Image taken from Twitter)

Next come the docstrings, the documentation inside your code files. We hit an apparent conflict here, since in theory, if your code is clean, it will not require documentation. However, note that we are no longer designing standalone systems that work as a black box. We are building protocols for decentralized applications, and your code will be called by all sorts of external agents. So by all means, document every function that's part of the contract's public API, following the NatSpec format.

Which brings me to the next point. I highly recommend that you document the specification of your protocol—that's how others will know what to call and what to expect. But more related to the topic at hand, in an audit, we check that the implemented code works as intended by the specification. That's why this document is a must: without it, auditors will just guess at your intentions, which might result in some issues getting missed because they're completely consistent within the system but take it to a state that you want to avoid.

Finally, there's the user documentation. For high-quality systems, writing the user documentation should be mostly painless. The moment things get cumbersome while documenting, consider re-evaluating your user stories, and don't be afraid to go back to iterate on them.

✔️ Check your dependencies

Your project builds on top of many, many others. It will probably depend at least on the Ethereum protocol and its network of nodes, and on Solidity, a bunch of Ethereum Improvement Proposals and their implementation, libraries for testing and UI, and maybe hundreds of other small projects. Even if yours is secure, you need to check how healthy your dependencies are, since they can easily become the source of vulnerabilities.

Earlier, I mentioned that your team should have strong and diverse knowledge. That includes knowledge of all the projects that surround you. You should be able to write idiomatic code following the best practices of the language, to identify and avoid known issues, always keeping an eye on new CVEs that may directly (or indirectly, through third-party dependencies) affect your project. Moreover, try to participate in the communities around your dependencies, as it's an excellent way to see firsthand how safe and trustworthy they are. You should also consider actively participating in those communities, to gain some karma that will surely come in handy later when you need new features and bug fixes.

Moreover, don't forget to pay attention to your dependencies' finances. When making your project's budget, take into account a share for your dependencies, as they may need it in order to remain actively maintained. There's a very nice project called OpenCollective, led by Pia Mancini, which is making it extremely easy to transparently support the organizations and developers you depend on.

Pia Mancini

Pia Mancini (Image taken from her website)

And, of course, with ZeppelinOS, we're building a platform that will let you vouch for the security of a package. It's in beta testing, so expect exciting news very soon.

Specific to Ethereum and Solidity, the community is collecting the lessons learned (usually in a painful way). You can learn a lot about interesting and tricky vulnerabilities playing the Ethernaut capture-the-flag game. We've published many of our past audits with descriptions of the issues found, recommendations, and usually a link to the patch that fixes them. All of our learnings from audits are distilled into the OpenZeppelin package, which you should definitely add to your list of dependencies—if you're not one of the thousands that already did. The Smart Contracts Weakness Registry maintained by the Mythril team is also a great resource for learning from the experience of others.

Whatever approach you take, remember that as the Ethereum space is very young and unexplored, we're learning many things as we go, so always proceed with caution.

✔️ Build your community

This is a complement to the first point: code without a community is insecure. The community gives you eyes to monitor the project, hands to test it in a real environment, support to survive challenging problems, and resilience to adjust to the unexpected. No amount of money, experience, or knowledge can substitute for this.

Once you publish the code, you can get started engaging your community. If your project is interesting, they will come, and this is where the cat-herding abilities of your team will shine. However, you definitely need to set up proper and fluent communication channels, invest in some marketing, and hire a bold community manager with a plan to disentangle and wisely leverage all the opportunities your community brings. I can't recommend highly enough the writings and videos by Jono Bacon, who has covered all the topics you can imagine about community management.

Jono Bacon

Jono Bacon in 2014 (Image taken from Flickr)

You should be thoughtful and caring with your community. A small step that goes a long way is to adopt and enforce a code of conduct so you can all feel safe. Then, write some contribution guidelines to make sure that all of their enthusiasm can be put to good use and they don't get lost. Lastly, think about setting up a bug bounty program that will encourage your community to watch out for vulnerabilities in the wild, providing hackers with enough incentives to disclose security issues in a responsible way.


tldr:

✅ Choose a free software license.

✅ Build a strong and diverse team of core maintainers.

✅️ Increase your bus factor: share knowledge and responsibilities.

✅ Choose a good leader.

✅️ Write clean code.

✅️ Enforce a consistent code style.

✅️ Ensure 100% unit test coverage.

✅️ Enforce green tests on all your pull requests.

✅️ Design your iterative development and testing process.

✅️ Publish your code.

✅️ Write a good README.

✅️ Document the functions of your public API.

✅️ Document your protocol.

✅️ Write the end-user documentation.

✅️ Make sure that your dependencies can be trusted.

✅️ Review known issues and keep an eye out for new ones.

✅️ Use OpenZeppelin, the community-vetted standard for smart contract development.

✅️ Build and care for your community.


Ready to hire an auditing team?

That's us! :) The Zeppelin team can help you assess the quality of your project and processes. We'll take a deep and thorough dive into your code, with years of experience hacking, researching, and developing on blockchains, plus a little touch of Latin American fire, to give you and your users all the confidence you need to continue building the core systems of this new decentralized, global, and open economy.

We're available for auditing services, so check out this information about security audits.

Thanks to Martín Abbatemarco for editing this post, to the Zeppelin team for the continuous experimentation and feedback, and to our customers for trusting us and helping us better understand what makes a free software project awesome.


Be part of our community

La obsolescencia de Java 8

El lenguaje de programación Java se había diseñado para ser un lenguaje que funcionara sin tener que crear código específico para cada sistema donde se ejecutaba. También tenía algo que trataba de destacar frente a otros, que una vez “compilado” podía usarse el mismo “binario” en otras plataformas.

Sin embargo, los planes para este lenguaje cambiaron hace tiempo por diversos motivos, entre otros porque hay sistemas donde no se permite la ejecución de código privilegiado si no se tiene autorización del fabricante, como es el caso de Apple en su sistema operativo macOS.

En la actualidad los propios autores de Java invitan a distribuir la máquina virtual con el propio programa creado en este para que pueda ejecutarse. Esto desvirtúa la utilidad con la que fue diseñado, no teniendo mayores ventajas con respecto a otros lenguajes de programación que podrían considerarse más eficientes.

Hay diversos motivos por los que distribuir programas sin el entorno de ejecución de Java y su máquina virtual han quedado relegados a nichos muy particulares (por ejemplo, servlets de contenedores EE, applets de hardware empotrado y Android) y fuera del software tradicional de escritorio. Por ejemplo, para ejecutar programas en macOS sin bloqueos de seguridad por no estar firmados, siendo obligatorio si el programa se pretende distribuir en la App Store.

A partir versión Java 11 se ha eliminado la tecnología Web Start del entorno de ejecución. Tampoco hay un instalador para usuarios finales, por lo que Java 8 es el último que se ofrece en el sitio web java.com, como parte de esta transición. Una salida que tienen los distribuidores de software desarrollado en Java para ambientes de escritorio pasa por incluir un entorno de ejecución OpenJDK. En una entrada anterior de este blog ya se mencionó esta necesidad.

Cabe mencionar que existe software de escritorio muy dependiente de Java, como es el caso de la firma de documentos PDF, donde las mejores librerías para manipular documentos con este tipo de elementos están programadas en Java. La implementación de referencia del estándar PAdES (DSS) utiliza este lenguaje, ya que librerías como iText/OpenPDF y Apache PDFBox siguen siendo las mejores para este propósito.

Herramientas implementadas en Java como el Firmador de documentos que hemos realizado utilizan todavía Java para toda la interfaz. Incluso está disponible una versión Web Start de Firmador (requiere tener Java 8 instalado o bien OpenJDK con Icedtea-web), demostrando de la mejor forma una tecnología obsoleta. Hay planes de crear una versión de Firmador que utilice Java solamente para la parte que sea necesaria. El resto utilizaría otro lenguaje de programación más portable y eficiente.

Cabe mencionar que para utilizar la obsoleta tecnología Web Start se ha requerido firmar el código con un certificado digital específico que tiene un costo anual significativo, sin embargo ya era necesario hacerse uno para crear ejecutables sin que aparezca el fatídico mensaje de “Windows protegió su PC”, por lo que la inversión estaba pensada para este caso. Para el caso de macOS también hay que costear aparte otro certificado oneroso para distribuir software.

En cuanto al sector público, los firmadores ya distribuían el entorno de ejecución de Java con sus propios instaladores, por lo que ya están preparados para el fin de Java 8 en los próximos meses.

Cómo instalar Firma Digital de Costa Rica en GNU/Linux Fedora 30

Esta guía documenta cómo instalar el controlador de la tarjeta de Firma Digital de Costa Rica y la jerarquía de certificados del Banco Central (SINPE) y del MICITT en el sistema operativo Fedora Workstation 30.

Las instrucciones están diseñadas para las distribuciones mencionadas previamente. Si se desea utilizar en distribuciones openSUSE Leap y Suse Linux Enterprise Server y Desktop, existe la guía sobre cómo instalar Firma Digital de Costa Rica en openSUSE Leap 15.1, SLES 15 SP1 y SLE 15 SP1. Para Debian y Ubuntu está la guía de cómo instalar Firma Digital de Costa Rica en Debian y Ubuntu.

Esta guía de instalación tiene los siguientes propósitos:

  • Configurar de la forma más sencilla y adecuada el sistema para que funcione con la mayor cantidad de programas.
  • Lograr que funcione para todos los usuarios del sistema, incluyendo los nuevos usuarios creados tras las instalación.
  • Aislar la librería de Firma Digital en una “caja de arena” (sandbox) para que funcione con múltiples usuarios del sistema simultáneamente (soluciona un defecto en la librería al crear ficheros temporales).

Instalación de las dependencias

  • Instalar el soporte CCID de PC/SC para que reconozca el lector de tarjetas e IcedTea-Web para poder cargar algunos lanzadores que usan Java Web Start como por ejemplo el del sitio web de CrearEmpresa.go.cr (los navegadores ya no soportan applets java, ya no es posible usar el del sitio web de la CCSS) y OpenJFX si pretende usarse algún firmador que lo use (NexU, por ejemplo).
    sudo dnf -y install pcsc-lite icedtea-web java-1.8.0-openjdk-openjfx

Descarga del “instalador”

  • Descargar el “instalador” en el desplegable llamado “Usuarios Linux” en la página de descarga de instaladores del sitio web de Soporte Firma Digital de Costa Rica, introduciendo el número de serie de la tarjeta y aceptando las condiciones.
  • Descomprimir el archivo zip descargado con unzip, en el momento de escribir esta documentación se llama sfd_ClientesLinux_RPM64_Rev11.zip. Se creará una carpeta llamada Firma Digital. Se asume que el archivo zip se ha descargado en la carpeta Descargas:
    cd ~/Descargas/
    
    unzip sfd_ClientesLinux_RPM64_Rev11.zip
    

Instalación de los certificados

Es necesario agregar a la lista de confianza la jerarquía de certificados del SINPE y del MICITT. En teoría solamente sería necesario instalar los certificados raíz del MICITT pero en la práctica hay algunas aplicaciones que necesitan los certificados intermedios del SINPE para completar la cadena a la hora de validar. Para ello, un conjunto de comandos:

  • Copiar los certificados:
    sudo cp -p ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/Certificados/* /usr/share/pki/ca-trust-source/anchors/
    
  • Regenerar los archivos de certificados para todas las aplicaciones:
    sudo update-ca-trust
    

Instalación del módulo PKCS#11

Aunque hay un módulo en el directorio Librerías, no es la versión más reciente y tiene varios defectos de enlazado. La versión distribuida en el paquete PinTool es más reciente y funciona correctamente en todos los programas probados. En el siguiente proceso se extrae y se instala conservando la fecha original de la librería.

  • Instalar el módulo PKCS#11 privativo en /usr/lib64/:
    cd ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/PinTool/IDProtect\ PINTool\ 6.41.01/RPM/
    
    rpm2cpio idprotectclient-641.01-0.x86_64.rpm | cpio -dim ./usr/lib/x64-athena/libASEP11.so
    
    sudo cp -p usr/lib/x64-athena/libASEP11.so /usr/lib64/
    
    sudo mkdir -p /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib64/libASEP11.so /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib64/libASEP11.so /usr/lib/
    
  • Permitir temporalmente al usuario local cargar aplicaciones gráficas con sudo (para gedit):
    xhost si:localuser:root
    
  • Crear el fichero /etc/Athena/IDPClientDB.xml y abrirlo para edición:
    sudo mkdir /etc/Athena/
    
    sudo gedit /etc/Athena/IDPClientDB.xml
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    <?xml version="1.0" encoding="utf-8" ?>
    <IDProtect>
     <TokenLibs>
      <IDProtect>
       <Cards>
        <IDProtectXF>
         <ATR type='hexBinary'>3BDC00FF8091FE1FC38073C821106600000000000000</ATR>
         <ATRMask type='hexBinary'>FFFF00FFF0FFFFFFFFFFFFFFFFF0FF00000000000000</ATRMask>
        </IDProtectXF>
       </Cards>
      </IDProtect>
     </TokenLibs>
    </IDProtect>
    
  • Crear un fichero llamado /usr/share/p11-kit/modules/firma-digital.module y abrirlo para edición:
    sudo gedit /usr/share/p11-kit/modules/firma-digital.module
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    remote: |bwrap --unshare-all --dir /tmp --ro-bind /etc/Athena /etc/Athena --proc /proc --dev /dev --ro-bind /usr /usr --symlink /usr/lib64 /lib64 --ro-bind /var/run/pcscd /var/run/pcscd p11-kit remote /usr/lib64/libASEP11.so
    

Eso es todo. Es necesario reiniciar Firefox y cualquier otra aplicación que use certificados para que se apliquen los cambios.

Quizás resulte interesante utilizar la herramienta Firmador, software libre para firmar documentos.

Road to #MozillaActivate, El Salvador 2018

Holi,

No se ustedes, pero de tanto estar viajando no me ha quedado demasiado tiempo para hacer tutoriales, pero me encanta documentar las cosas asi que esta vez vamos a hablar sobre la fundación Mozilla y porque fue que pare una semana en El Salvador. Bienvenidos.

Antecedentes ( esto ya parece un informe jajaja, pero vamos a hacerlo bonito).

El año pasado para el encuentro Centroamericano de Software Libre, Costa Rica 2017 hubo un evento alterno llamado #mozillaActivate, resulta que en el mismo encuentro hubo gente de #mozillaCentroamerica invitando a mas gente a unirse al movimiento de una internet libre, respetuosa con la privacidad y los derechos ( sí sé que suena medio raro,  pero lo que mozilla incentiva es que tengamos una internet libre y que todos seamos tratados por igual) a mi me parece excelente muchas cosas que esta haciendo Mozilla hasta que me dieron en el kokoro con algo llamado Web of things, que es una solución para el internet de las cosas preparada por Mozilla que realmente tiene un muy muy buen punto a su favor, Es realmente sencillo crear soluciones con su propuesta.
El contacto directo con Mozilla Centroamérica fue MoziKarlita, que amablemente nos invito a ser parte de Mozilla Centroamérica y pues con Lexo, dijimos esta bien.

Preparación del evento

Ponernos de acuerdo fue lento, tedioso y complicado.
Lo sé son palabras duras para un equipo que ya había trabajado junto, en este caso nosotros como integrantes nuevos de Mozilla Centroamérica y primeros miembros de Mozilla Guatemala fue un poco confuso saber como ayudar, ellos tenían sus métodos para hacer las cosas y yo y mis manías por andar mandando no se sintieron bien.

Realmente de lo único que puedo quejarme fue de que entre todo dejamos muchas cosas para el ultimo minuto, como yo por ejemplo perdiendo mi tarjeta del banco sin haber comprado los boletos de ida y vuelta a El Salvador, los que me siguen en Instagram, facebook y Twitter (@yeffrimic) se dieron cuenta de que mi mente andaba en otro lado y pues aquí oficialmente me disculpo, La cague jajaja.

La parte mas complicada de todo fue el hecho de que nadie quiso tomar la batuta de líder al principio  y se tuvieron que hacer malabares para que mozilla nos autorizara el evento y nos patrocinara. Al final y lo que importa fue que Mozilla nos aprobó el patrocinio (gracias David) y pues bueno ya teníamos todo preparado, charlas, presentaciones, lugar para dar las charlas asi que yeii, ya había viaje confirmado para El Salvador, Mozilla Activate y ECSL alla vamos.

Nos vamos a San Salvador, Gracias Mozilla

20180710_083538Él es Lexo, vive a 12 horas de la Ciudad de Guatemala y como a 24 de San Salvador.

Bueno al final llegamos a San Salvador, salimos mas o menos a las 7 am y llegamos al medio día, listos para descansar y preparar todo para el día D

Día de exposiciones

Dejo la hermosa agenda aqui y dare mis impresiones de todos.

https://docs.google.com/document/d/1v9SlhDQ9EHm0Tdn14UlzivmkibtT08yIvotK7XAawcI/edit?usp=sharing

Todos y cada uno de los que están en Mozilla CentroAmerica como representantes o asistieron como conferencistas al Mozilla Activate son unos putos cracks.

Empezando con Aaron y su increible manera de exponer porque Mozilla y no solo firefox sino todo lo que representa la fundación es de las mejores cosas en internet hoy en dia.

photo5059894245955053519

 

Roni y su dominio con los temas de privacidad en la red

photo5059856768070428666

no hablemos de Lexo, Carcamo con Rust que los vi por allí haciendo travesuras con uno de los lenguajes mas nuevos y potentes del momento.

photo5059856768070428659

 

photo5059856768070428660

Me impresiono bastante lo que puede hacer Firefox con web VR a cargo de David

photo5059894245955053522

 

Jorge estuvo hablando sobre programacion de videojuegos pero murphy fue su enemigo mortal no pudiendo proyectar porque el adaptador que tenía no funcionaba 😦
photo5059856768070428656
aqui esta con lexo tratando de solucionarlo, no se para que usan mac jajaja

moziKarlita hablando sobre la comunidad de mozilla y como ser parte de ella tambien alentó a muchos jovenes que estaban presentes.

photo5059856768070428664

 

y yo merengues hablando sobre lo que me encanta Internet de las cosas con al go llamado Mozilla IOT, y su web de las cosas, adjunto la presentación para que le echen un ojo, como he dicho antes esta es una excelente iniciativa de parte de Mozilla y todos los voluntarios para el internet de las cosas

photo5059856768070428668

 

Bueno, después de organizar, moverse y el calor de San Salvador cada uno fue cayendo a lo largo de la semana dormido por el cansancio unos en el ECSL y otros en el dia social y yo que siempre andaba con sueño.

photo5059894245955053517

Al final fue una experiencia increible hablandole a poco mas de 100 patojos( jovenes ) acerca de las bondades de fundación mozilla el proximo año será en Guatemala asi que quedan todos invitados a asistir.  No les conté muchas cosas que sucedieron para que el proximo año nos acompañen en Guatemala jajaja.

Con esto termino el articulo del dia de hoy pronto mas acerca de las microfaventuras .

Recuerden, solo necesitan una excusa para cambiar el mundo.

 

 

Guías de instalación de Firma Digital en GNU/Linux actualizadas

Se han actualizado las guías de instalación de Firma Digital de Costa Rica para GNU/Linux para Ubuntu y Fedora. Los cambios amplían la cantidad de software soportado, mayor estabilidad y otras ventajas.

Aislamiento de la librería en caja de arena

Una de las mejoras comunes en ambos sistemas permiten el aislamiento de la librería privativa en una “caja de arena” (sandbox). El propósito de este aislamiento es evitar caídas de los programas cuando dos usuarios distintos del mismo sistema tratan de acceder a la tarjeta. Esto es debido a que la librería libASEP11.so genera unos temporales en el directorio /tmp/ con un usuario, pero cuando intenta crearlos desde otro usuario diferente, la librería genera un error de segmentación que se propaga a la aplicación que la está utilizando.

Para solucionar el problema se utiliza un sistema de caja de arena que puede lanzarse sin privilegios administrativos mediante la herramienta bubblewrap, que permite montar en un espacio de nombres vacío del espacio de usuario la librería, por lo que en el caso de que dos usuarios del sistema utilicen la librería, la ruta /tmp/ estará aislada en ambos casos, no existiendo en el sistema de ficheros físico, evitando el problema mencionado.

Otra ventaja que se obtiene con este aislamiento es que la librería no genera el directorio oculto ~/.ase/ en los directorios de los usuarios, que llega a suponer una molestia cuando se generan búsquedas, ya que el directorio lo genera con permisos que impiden su acceso por defecto. Por otra parte, al tratarse de software privativo y no poder auditar el código fuente, el aislamiento mejora ligeramente la seguridad sobre lo que pueda realizar esta librería.

Otra característica que permite resolver este defecto es poder utilizar la tarjeta de Firma Digital para iniciar sesión con el PIN de la tarjeta de Firma Digital, desde la ventana de selección de usuario (gdm, GNOME Display Manager) si se configura localmente con algún mecanismo tipo pam_pkcs11. Antes no se podía realizar porque el plug-in gsd-smartcard de GNOME Settings Daemon, encargado de comunicarse con la tarjeta, se ejecuta con otro usuario distinto al de la sesión (en este caso, gdm). Antes de esta solución, cuando un usuario inicia sesión en el sistema, ese servicio quedaba activo con los ficheros generados en /tmp/ y provocaba que cualquier proceso que utilizara Firma Digital en la sesión de usuario se cerrara automáticamente, provocando gran inestabilidad.

El método que se ha emplado para resolverlo ha sido mediante la característica remote de p11-kit. P11-kit es parte del proyecto p11-glue, cuyo propósito es actuar de “pegamento” para consolidar todas las herramientas criptográficas del sistema y permitir estandarizar el acceso a servicios con dispositivos PKCS#11 de forma unificada. En la actualidad dispone de integración con características PKCS#11 de GnuTLS, NSS, OpenSSL, OpenSC, Java, y otros, así como la confianza de las autoridades de certificación (CA).

Hasta ahora se estaba utilizando p11-kit con un módulo que hacía referencia a una librería local (libASEP11.so). Sin embargo, p11-kit permite cargar módulos de forma remota, que puede resultar interesante para utilizar un dispositivo criptográfico existente en otra computadora, si bien en esta solución no se ejecuta nada remoto sino que sigue en local. El parámetro remote permite lanzar un comando personalizado que en este caso invoca el ejecutable brwap de bubblewrap, aislando la librería en esta caja de arena.

Gracias a esta mejora, en próximas entradas de blog explicaría cómo iniciar sesión en el sistema mediante Firma Digital y cómo bloquear la pantalla (sesión) extrayendo la tarjeta del lector.

Soporte de NSS (Chromium, Evolution, Acceso a llaveros) en Ubuntu

Se ha actualizado la guía de Ubuntu para incorporar un reemplazo de la librería NSS genérica del sistema (NSS es la librería de servicios de seguridad de Mozilla), utilizada (además de Firefox y Thunderbird) por el navegador Chromium, cliente de correo Evolution o el acceso a llaveros, para poder utilizar Firma Digital desde ellos. Esto ya era posible con la guía de Fedora, pero no en Ubuntu hasta ahora.

Integración mejorada en Fedora

Fedora, así como Red Hat, ha sido siempre la distribución GNU/Linux que desde mi punto de vista se ha esforzado más en integrar los sistemas criptográficos, utilizados en sector público y corporativo. En la última actualización que se incluye a partir de Fedora 29 completan la consolidación para poder cargar el módulo p11-kit-proxy desde la configuración de política de NSS para poder cargar módulos de terceros sin tener que realizar enlaces simbólicos como hasta ahora.

Fedora ya llevaba tiempo reemplazando libnssckbi.so (librería de módulos de seguridad de NSS) con p11-kit-trust por defecto, algo que permite unificar la confianza en los certificados de las CA de forma centralizada. También está unificada la configuración de cifrados utilizados en TLS a nivel de todo el sistema, para prevenir brechas de seguridad por configuraciones débiles. En este aspecto es indiscutiblemente la distribución mejor preparada, así como los aportes con los que se han beneficiado otras distribuciones, ya que se esfuerzan en que estas mejoras se incorporen en las versiones oficiales del software (upstream).

En una próxima entrada de blog mostraré cómo iniciar sesión localmente (sin sssd, usando pam_pkcs11 con mapeo local, sin LDAP) con la tarjeta de Firma Digital.

Cómo instalar Firma Digital de Costa Rica en GNU/Linux Ubuntu 18.04, 19.04, Debian 9 y 10

Esta guía documenta cómo instalar el controlador de la tarjeta de Firma Digital de Costa Rica y la jerarquía de certificados del Banco Central (SINPE) y del MICITT en los sistemas operativos Ubuntu 18.04 LTS, Ubuntu 19.04, Debian 9 y 10.

Las instrucciones están diseñadas para las distribuciones mencionadas previamente. Si se desea utilizar en distribuciones Fedora y Red Hat Enterprise Linux, existe la guía sobre cómo instalar Firma Digital de Costa Rica en Fedora, Red Hat Enterprise Linux 8 y CentOS 8. Para openSUSE Leap y Suse Linux Enterprise Server y Desktop está la guía de cómo instalar Firma Digital de Costa Rica en openSUSE Leap 15.1, SLES 15 SP1 y SLE 15 SP1.

Esta guía de instalación tiene los siguientes propósitos:

  • Configurar de la forma más sencilla y adecuada el sistema para que funcione con la mayor cantidad de programas.
  • Lograr que funcione para todos los usuarios del sistema, incluyendo los nuevos usuarios creados tras las instalación.
  • Aislar la librería de Firma Digital en una “caja de arena” (sandbox) para que funcione con múltiples usuarios del sistema simultáneamente (soluciona un defecto en la librería al crear ficheros temporales). Esta característica no está disponible en Debian 9.

Instalación de las dependencias

  • Instalar el soporte CCID de PC/SC para que reconozca el lector de tarjetas e IcedTea-Web para poder cargar algunos lanzadores que usan Java Web Start como por ejemplo el del sitio web de CrearEmpresa.go.cr (los navegadores ya no soportan applets Java, ya no es posible usar el firmador de la CCSS) y OpenJFX si pretende usarse algún firmador que lo use (NexU, por ejemplo). Bubblewrap es la herramienta para aislar la librería en la caja de arena. Binutils y sudo no vienen instalados en Debian por defecto.
    sudo apt -y install pcscd bubblewrap icedtea-netx openjfx binutils sudo
    

En el caso de Debian, para poder usar los comandos con sudo, ejecutar como root usermod -a -G sudo nombredeusuario reemplazando nombredeusuario por el nombre de usuario que se desee usar con sudo y reiniciar para aplicar cambios. En Ubuntu no es necesario este paso.

Descarga del “instalador”

  • Descargar el “instalador” en el desplegable llamado “Usuarios Linux” en la página de descarga de instaladores del sitio web de Soporte Firma Digital de Costa Rica, introduciendo el número de serie de la tarjeta y aceptando las condiciones.
  • Descomprimir el archivo zip descargado con unzip, en el momento de escribir esta documentación se llama sfd_ClientesLinux_DEB64_Rev11.zip. Se creará una carpeta llamada Firma Digital. Se asume que el archivo zip se ha descargado en la carpeta Descargas:
    cd ~/Descargas/
    
    unzip sfd_ClientesLinux_DEB64_Rev11.zip
    

Instalación de los certificados

Es necesario agregar a la lista de confianza la jerarquía de certificados del SINPE y del MICITT. En teoría solamente sería necesario instalar los certificados raíz del MICITT pero en la práctica hay algunas aplicaciones que necesitan los certificados intermedios del SINPE para completar la cadena a la hora de validar. El último instalador también incluye una CA del BCCR, probablemente para el certificado de código de su propio firmador (que en teoría tampoco debería ser necesario si el sistema operativo está correctamente actualizado). Para ello, un conjunto de comandos:

  • Copiar los certificados:
    sudo cp -p ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/Certificados/* /usr/local/share/ca-certificates/
    
    sudo rename.ul -- .cer .crt /usr/local/share/ca-certificates/*.cer
    
    for file in /usr/local/share/ca-certificates/*.crt; do sudo openssl x509 -inform DER -in "$file" -out "$file.tmp"; done 2>/dev/null
    
    sudo find /usr/local/share/ca-certificates/ -type f -empty -delete
    
    sudo rename.ul -- .tmp '' /usr/local/share/ca-certificates/*.tmp
    
  • Regenerar los archivos de certificados para todas las aplicaciones:
    sudo update-ca-certificates --fresh
    

Instalación del módulo PKCS#11

Aunque hay un módulo en el directorio Librerías, no es la versión más reciente y tiene varios defectos de enlazado. La versión distribuida en el paquete PinTool es más reciente y funciona correctamente en todos los programas probados. En el siguiente proceso se extrae y se instala conservando la fecha original de la librería.

  • Instalar el módulo PKCS#11 privativo en /usr/lib/x86_64-linux-gnu/:
    cd ~/Descargas/sfd_ClientesLinux_Rev11/Firma\ Digital/PinTool/IDProtect\ PINTool\ 6.41.01/DEB/
    
    ar p idprotectclient_641.01-0_amd64.deb data.tar.gz | tar zx ./usr/lib/x64-athena/libASEP11.so
    
    sudo cp -p usr/lib/x64-athena/libASEP11.so /usr/lib/x86_64-linux-gnu/
    
    sudo mkdir -p /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib/x86_64-linux-gnu/libASEP11.so /usr/lib/x64-athena/
    
    sudo ln -s /usr/lib/x86_64-linux-gnu/libASEP11.so /usr/lib/
    
  • Crear el fichero /etc/Athena/IDPClientDB.xml y abrirlo para edición:
    sudo mkdir /etc/Athena/
    
    sudo gedit /etc/Athena/IDPClientDB.xml
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    <?xml version="1.0" encoding="utf-8" ?>
    <IDProtect>
     <TokenLibs>
      <IDProtect>
       <Cards>
        <IDProtectXF>
         <ATR type='hexBinary'>3BDC00FF8091FE1FC38073C821106600000000000000</ATR>
         <ATRMask type='hexBinary'>FFFF00FFF0FFFFFFFFFFFFFFFFF0FF00000000000000</ATRMask>
        </IDProtectXF>
       </Cards>
      </IDProtect>
     </TokenLibs>
    </IDProtect>
    
  • Crear un fichero llamado /usr/share/p11-kit/modules/firma-digital.module y abrirlo para edición:
    sudo gedit /usr/share/p11-kit/modules/firma-digital.module
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    remote: |bwrap --unshare-all --dir /tmp --ro-bind /etc/Athena /etc/Athena --proc /proc --dev /dev --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /var/run/pcscd /var/run/pcscd p11-kit remote /usr/lib/x86_64-linux-gnu/libASEP11.so
    

    Solamente para Debian 9 (sí funciona en Debian 10): la línea anterior no funciona porque incluye una versión demasiado antigua de p11-kit. En su lugar debe usarse esta otra línea: module: /usr/lib/x86_64-linux-gnu/libASEP11.so

  • Crear un fichero llamado /usr/local/sbin/update-p11-kit-symlinks y abrirlo para edición:
    sudo gedit /usr/local/sbin/update-p11-kit-symlinks
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    #!/bin/sh
    
    FIREFOX_LIB=/usr/lib/firefox/libnssckbi.so
    FIREFOX_ESR_LIB=/usr/lib/firefox-esr/libnssckbi.so
    THUNDERBIRD_LIB=/usr/lib/thunderbird/libnssckbi.so
    NSS_LIB=/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
    
    if [ -e "$FIREFOX_LIB" ]
    then
        if ! [ -L "$FIREFOX_LIB" ]
        then
            echo "Firefox libnssckbi.so is not a symlink. Fixing..."
            mv -f "$FIREFOX_LIB" "$FIREFOX_LIB".bak
            ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$FIREFOX_LIB"
        fi
    fi
    
    if [ -e "$FIREFOX_ESR_LIB" ]
    then
        if ! [ -L "$FIREFOX_ESR_LIB" ]
        then
            echo "Firefox ESR libnssckbi.so is not a symlink. Fixing..."
            mv -f "$FIREFOX_ESR_LIB" "$FIREFOX_ESR_LIB".bak
            ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$FIREFOX_ESR_LIB"
        fi
    fi
    
    if [ -e "$THUNDERBIRD_LIB" ]
    then
        if ! [ -L "$THUNDERBIRD_LIB" ]
        then
            echo "Thunderbird libnssckbi.so is not a symlink. Fixing..."
            mv -f "$THUNDERBIRD_LIB" "$THUNDERBIRD_LIB".bak
            ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$THUNDERBIRD_LIB"
        fi
    fi
    
    if [ -e "$NSS_LIB" ]
    then
        if ! [ -L "$NSS_LIB" ]
        then
            echo "NSS libnssckbi.so is not a symlink. Fixing..."
            mv -f "$NSS_LIB" "$NSS_LIB".bak
            ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$NSS_LIB"
        fi
    fi
    
  • Agregar el atributo de ejecutable al script:
    sudo chmod +x /usr/local/sbin/update-p11-kit-symlinks
    
  • Crear un fichero llamado /etc/systemd/system/p11-kit-proxy-updater.service y abrirlo para edición:
    sudo gedit /etc/systemd/system/p11-kit-proxy-updater.service 
    
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
    [Unit]
    Description=mantenimiento de enlaces a p11-kit-proxy
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/sbin/update-p11-kit-symlinks
    
    [Install]
    WantedBy=multi-user.target
    
  • Activar el servicio al arranque y ejecutarlo una primera vez para comprobar que funciona:
    sudo systemctl enable --now p11-kit-proxy-updater.service
    

Solamente para Ubuntu 18.10, Debian 10 y posteriores: a partir de versiones recientes de p11-kit hay que modificar el fichero /usr/share/p11-kit/modules/p11-kit-trust.module y eliminar o desactivar la línea disable-in: p11-kit-proxy agregando un “#” al inicio de esa línea.

sudo gedit /usr/share/p11-kit/modules/p11-kit-trust.module

La línea quedaría como sigue, el resto no hay que modificarlo:

#disable-in: p11-kit-proxy

Eso es todo. Es necesario reiniciar Firefox y cualquier otra aplicación que use certificados para que se apliquen los cambios. Si se ha insertado el lector y la tarjeta al lector, estas aplicaciones preguntarán por el PIN en páginas donde se solicite autenticación (por ejemplo en el sitio web de Internet Banking del Banco Nacional), lo que indicará que se la instalación ha sido exitosa.

Si el componente de firma del Banco Central está instalado debería funcionar para poder realizar la prueba de firma. El sitio web de Soporte Firma Digital podría usar todavía la prueba de Java y no funciona con los navegadores modernos. En su lugar podría usarse la prueba con el firmador BCCR desde la página de Firma Digital de verificación de certificados (requiere instalar los certificados para poder entrar).

Quizás resulte interesante utilizar la herramienta Firmador, software libre para firmar documentos.