Wiki

Firma Electrónica Avanzada

Descripción General

Según la Ley Nº 18.600 del 21 de setiembre de 2009, la Firma Electrónica Avanzada es una Firma Electrónica que además:

  1. requiere información de exclusivo conocimiento del firmante, permitiendo su identificación unívoca.
  2. debe ser creada por medios que el firmante pueda mantener bajo su exclusivo control;
  3. debe ser susceptible de verificación por terceros;
  4. debe estar vinculada a un documento electrónico de tal modo que cualquier alteración subsiguiente en el mismo sea detectable; y
  5. debe haber sido creada utilizando un dispositivo de creación de firma técnicamente seguro y confiable y estar basada en un certificado reconocido válido al momento de la firma.

La firma electrónica avanzada tiene idéntica validez y eficacia que la firma autógrafa consignada en documento público o en documento privado con firmas certificadas, por lo que no requiere acuerdo previo para su uso. Además, provee garantías de Integridad, Autenticidad y No repudio sobre los documentos intercambiados. Esto hace que su uso permita la eliminación completa del papel en cualquier acto entre partes públicas o privadas, constituyendo un elemento fundamental para el desarrollo de la sociedad digital.

En la práctica, una Firma Electrónica Avanzada es una firma hecha con pares de llaves asimétricas y certificados x509 tradicionales, con las particularidades de que el certificado debe ser emitido por una autoridad acreditada ante la Unidad de Certificación Electrónica (UCE), y que además la llave privada debe residir en un dispositivo seguro de creación de firmas. En el caso de firmas de persona física, se exige que el dispositivo seguro de creación de firmas sea un un token criptográfico, tarjeta inteligente, HSM u otro dispositivo que otorgue garantías de seguridad equivalentes, mientras que para la firma de persona jurídica se admite el uso de dispositivos de software, dado que el uso es previsto para sistemas automáticos y por lo tanto el riesgo asociado a la mala manipulación de la llave privada es considerablemente menor. Los prestadores acreditados son Abitab (https://www.id.com.uy), el Correo (http://www.correo.com.uy/index.asp?codPag=firmaDig) y el Ministerio del Interior para los certificados de la CI Electrónica (https://www.minterior.gub.uy/index.php/firma-electronica-avanzada). Cada uno tiene en sus respectivos sitios web el procedimiento para la solicitud de sus certificados, además de la información adicional requerida como declaraciones de políticas, certificado propio, listas de revocación, etc.

En el esquema de firma avanzada más común, el firmante realiza un hash del documento electrónico, lo cifra con su llave privada y anexa el resultado al documento como prueba de la firma del mismo. La contraparte, usando el certificado público del firmante (en particular su llave pública) puede descifrar el hash originalmente enviado y puede compararlo contra el hash calculado nuevamente del documento que recibió. Si coinciden, la contraparte puede tener la certeza de que el documento no fue modificado por una tercera parte (Integridad) y que además fue firmado por la persona, física o jurídica, que figura identificada en el certificado (Autenticidad). Debido a que el certificado público del firmante fue emitido por un prestador acreditado y confiable, sus procedimientos de registro garantizan efectivamente la identidad del firmante (No Repudio).

Por todo esto, la firma electrónica avanzada es el mecanismo de firma recomendado para cualquier transacción o intercambio de documentación que requiera firma de la contraparte, y también puede ser usada para autenticación fuerte.

Implementación de la Firma

Siguiendo el esquema anteriormente mencionado, cualquier sistema que desee implementar la firma electrónica avanzada debe acceder a la llave privada del firmante y cifrar un hash del documento que desea hacerlo firmar, siendo la implementación concreta dependiente de la plataforma obviamente. Siempre el acceso a la llave privada estará protegido por un secreto que el firmante debe cuidar, que es el PIN o contraseña. Este secreto puede que sea usado para autenticarse ante un dispositivo y habilitar acceso a los comandos de uso de la llave como en la CI electrónica o directamente para descifrar el contenedor de software donde se almacena la llave, dependiendo del escenario de uso, pero a nivel conceptual es lo que garantiza al firmante que aún siendo comprometido el soporte en el que tiene la llave sigue manteniendo control exclusivo sobre la misma. Es por esto que el almacenamiento de pines o contraseñas, especialmente en el caso de personas físicas, es algo totalmente riesgoso y desaconsejable.

Firma de Persona Física

Es el caso en que una persona física desea comprometerse con el contenido de un documento, por ejemplo para firma de un contrato, de un formulario, una transacción bancaria, etc. La particularidad que presenta es que, al ser emitida exclusivamente en dispositivos criptográficos, el software que desee implementar firma avanzada de persona física deberá necesariamente acceder a estos dispositivos. Para el caso de la CI Electrónica, se recomienda ver la sección especialmente dedicada a la misma, ya que si bien es similar a los demás dispositivos, presenta algunas particularidades y opciones de implementación adicionales. Ver CI Electrónica.

El caso más básico se da cuando el usuario tiene que firmar documentos de elaboración manual como cartas, contratos, acuerdos, formularios descargables o similares. En estos casos lo más sencillo es que el usuario elabore o complete el documento en su editor de texto de preferencia, lo exporte como PDF, lo firme localmente con su CI Electrónica o su dispositivo de seguridad de preferencia y lo remita a la otra parte por el medio que considere adecuado, que puede ser directamente un correo electrónico, upload de archivo o cualquier otra vía electrónica. En el caso de firma de contratos, términos y condiciones y similares, puede que ni siquiera sea necesario editar nada, simplemente se abre el PDF que se recibió, se lo firma y se lo devuelve a la contraparte. Para firmar un PDF localmente en su PC con Adobe Reader se puede consultar el siguiente instructivo: Firmar PDF en Adobe Reader.

Cuando se quiere implementar un sistema que reciba documentación firmada, las opciones son muchas. Una primera aproximación sencilla es la contraparte de la anterior: solicitar al usuario que firme su documento fuera del sistema y que lo cargue al mismo ya firmado. Si bien a priori puede ser percibido como incómodo desde el punto de vista funcional, existen casos de uso donde es la opción más directa a implementar, como el que se ve en la siguiente figura.

Se trata de una empresa u organismo del estado (Sistema de Gestión) que requiere que un usuario realice cierta operativa, posiblemente además en nombre de una empresa u organismo, y tiene como parte de la misma la inclusión de informes técnicos firmados por terceros, como por ejemplo planos, balances, informes de auditorías, revisiones, etc. Que el gestor reciba los documentos firmados en papel y los escanee no es una opción sólida porque se pierde el carácter de original, por lo que para un uso 100% electrónico se deberían pedir los informes digitales. Si bien el sistema podría implementar la funcionalidad de que cada uno de los terceros suba su propio informe y lo firme electrónicamente, esto sería incómodo y difícil de coordinar. Resulta natural entonces que el gestor pida a cada tercero que remita su informe ya firmado por mail u otra vía, y que sea éste quien se encargue de la gestión ante la empresa u organismo, remitiendo en el proceso los informes originales firmados digitalmente por cada uno de los profesionales. Si se utiliza formato de documentos PDF cada tercero puede realizar la firma digital en su PC de forma sencilla con su CI Electrónica u otro dispositivo criptográfico usando Adobe Reader de la misma forma que ya fue mencionada para el caso de que una persona enviaba una carta o solicitud firmada digitalmente.

Más allá de los ya mencionados casos en donde lo más conveniente es que el usuario firme en su PC y envíe por mail, existen muchos casos en donde esto no es cómodo, como por ejemplo cualquier sistema que modele un proceso de negocio donde la firma de un documento es un paso más del proceso. En esos casos, lo más conveniente es que el propio sistema implemente la firma como parte del mismo, y para ello hay varias alternativas.

PKCS#11

PKCS#11 es una interfaz estándar para el acceso a dispositivos criptográficos, y por lo tanto es una alternativa natural para implementar firma electrónica avanzada con cualquier token o con la CI Electrónica. Por más información para su implementación se recomienda ver Autenticación y Firma Avanzada a través de PKCS#11.

Servicio de Firma con CI Electrónica

AGESIC cuenta con una plataforma que ofrece firma con CI electrónica como servicio. que ofrece facilidad de integración con aplicaciones por utilizar protocolos estándar y maduros para la integración y, al basarse en plugins y componentes de browser y ser específicamente diseñada para usar la CI uruguaya, provee una experiencia de usuario de gran calidad. Su funcionamiento esencial es sencillo: Cuando una aplicación web quiere recoger la firma electrónica avanzada de una persona, en lugar de realizarla localmente, redirige a la misma a esta plataforma delegando la firma en este servicio. La aplicación recibe el documento ya firmado, y esta puede efectuar la validación del mismo para asegurarse que todo está correcto.

Las restricciones para su uso son que aplica solamente a aplicaciones web, y que los plugins son sólo para versiones desktop de los navegadores, así que si bien se tiene un alto nivel de compatibilidad en PC y navegadores tradicionales, de momento no soporta los entornos Mobile. Las ventajas que ofrece usar esta plataforma son la simplicidad en la implementación y la experiencia del usuario final, por lo que es la opción recomendada siempre salvo cuando el entorno de los usuarios no sea compatible y/o cuando no se quiera incurrir en dependencia de un servicio externo. En esos casos se recomienda implementar una solución propia, para lo cual se puede ir por alguna de las soluciones alternativas ya mencionadas.

La documentación de la misma puede encontrarse en la página dedicada al Servicio de Firma con la CI Electrónica.

Servicio de Autenticación con CI Electrónica

Dado que el sistema de llaves asimétricas y certificados del que consiste la firma electrónica avanzada también puede ser utilizado para la autenticación, muchas de las técnicas mencionadas anteriormente pueden ser utilizadas en forma prácticamente análogas para realizar la autenticación de usuarios. En particular, para la autenticación utilizando al CI Electrónica AGESIC cuenta con un servicio análogo al servicio de firma de la sección anterior.

La documentación del mismo puede encontrarse en la página dedicada al Servicio de Autenticación con la CI Electrónica.

Firma de Persona Jurídica

Por ser una Firma Electrónica Avanzada, la firma de persona jurídica también se basa en el uso de una llave privada para firmar documentos y una llave pública extraída del certificado para validar. La diferencia es que el sujeto registrado en el certificado es una persona jurídica, es decir, *una organización*. En el mundo físico, pensar en firma de organización carece de sentido, puesto que la organización en sí misma no tiene voluntad, y siempre son personas físicas las que actúan en su nombre. Si bien en el mundo digital esto se mantiene, y las actuaciones fundamentales de las organizaciones siguen siendo realizadas por personas físicas en su nombre, existe la posibilidad de que *los sistemas de la organización realicen actuaciones en forma autónoma, sin intervención humana directa*, y para dotar de seguridad y garantías jurídicas esos actos es que se crea y reconoce la firma electrónica avanzada de persona jurídica como tal. Casos de uso de firma de persona jurídica incluyen la facturación electrónica, la emisión de constancias, la firma de documentos para certificar que se controló alguna regla de negocio explícitamente, la autenticación de transacciones que se realizan automáticamente, entre otros.

En este escenario entonces, las claves y certificados de la persona jurídica se instalarán en el equipo en que se encuentre la aplicación que los acceda, que será típicamente en un servidor físico o virtual, y la o las aplicaciones accederán al certificado y las llaves en forma automática autenticándose debidamente. En este sentido, el acceso a las llaves por parte de las aplicaciones se vuelve mucho más directo que en el caso de persona física, ya que en este caso siempre se estará ejecutando en el mismo equipo donde se encuentra el dispositivo de creación de firmas, sea este de software o de hardware.

Tanto en caso de software como de hardware, se recomienda usar las llaves utilizando bibliotecas estables y maduras de la propia plataforma en la que se esté trabajando. Si se trata de un dispositivo de software, es decir, un archivo PKCS#12, se debe utilizar una biblioteca para acceso a PKCS12 y proveer la contraseña de acceso, mientras que si se trata de un dispositivo de hardware, se debe usar un pkcs11 Provider instanciado con el driver del dispositivo (que debe estar previamente instalado) y el correspondiente PIN de acceso. Si se tratase de un HSM, es posible que además se requiera una activación fuera de banda del mismo, que es específica de cada marca y modelo, y se determina al momento de la instalación del mismo.

Para facilitar la realización de firmas de persona jurídica, AGESIC cuenta con dos recursos de Software Público para ello. El hecho de que sean componentes de Software Público implica que el código es abierto y libre para su uso, reproducción y modificación, pero que AGESIC no asume ninguna responsabilidad sobre la calidad, mantenimiento o soporte sobre el mismo. Dicho de otra forma, el uso de estos componentes es libre para cualquier aplicación pública o privada, pero quien lo integra debe hacerse cargo del mismo como parte de su producto o sistema.

  • El primer componente se trata de una API de firma, que encapsula el acceso a las llaves de persona jurídica para la firma de archivos PDF y XML en forma sencilla. Tiene la restricción que no soporta aún dispositivos PKCS#11 (tokens, HSM, etc.). https://git.agesic.gub.uy/seguridad-informatica/api-java-de-firma-electronica
  • El segundo es el ya mencionado componente de firma, pero que en las últimas versiones incorpora la mencionada API en su parte servidor, para ser accedida como Webservice. Tiene la ventaja que de que puede ser integrada a otras plataformas además de Java por tener un acoplamiento más bajo, pero tiene la desventaja que genera una comunicación entre aplicaciones para firmar, y otro actor podría invocar la firma también, por lo que debe ser utilizada con ese riesgo en mente. https://git.agesic.gub.uy/seguridad-informatica/componente-firma-electronica

De cualquier manera, estos recursos de AGESIC pueden ser utilizados como implementación de referencia para guiar la implementación nativa en la plataforma y/o sistema en que se esté trabajando. Realmente, la implementación de la firma electrónica es sencilla, y particularmente sencilla lo es la implementación de la firma de persona jurídica.

Estándares de Firma en Documentos

en construcción...

La firma electrónica avanzada es un mecanismo que agrega información al documento para dotarlo de, mínimamente, capacidad de verificación de integridad e identificación del firmante. Es importante este detalle, debido a que los datos agregados no previenen que el documento sea modificado, sino que hacen que las modificaciones sean detectables, es decir, lo hacen *suceptible de verificación*. Para que esa verificación sea posible, la firma debe ser expresada de una forma que pueda ser interpretada por quien la verifica, y es por eso que existen los estándares de firma electrónica. Cada tipo de documento tiene un conjunto de extensiones estándar que especifican cómo deben ser expresados los resultados de las firmas, y cada validador de firmas para esos documento usa esas mismas extensiones para efectuar las validaciones.

Es así que existen los siguientes estándares de firma que vale la pena destacar:

  • PDF Signature
  • PAdES
  • XML Signature
  • XAdES
  • CMS
  • CAdES

Validación de Firma Electrónica Avanzada

La validación de la firma es el proceso mediante el cual un receptor de un documento se asegura de la integridad y no repudio del mismo por parte del firmante, y sigue una serie de pasos bien definida, aunque su implementación concreta pueda diferir un poco según el entorno de implementación. En cualquier caso, una condición necesaria para poder validar la firma es contar con el certificado del firmante. Los estándares de firma anteriormente mencionados establecen campos específicos donde se coloca el certificado al momento de realizar la firma. Análogamente, el validador puede obtener el certificado de allí. Si esta opción no fuese posible, el validador debe obtener el certificado por alguna otra vía, como ser un directorio público o tenerlo previamente porque fue entregado fuera de banda. De todas formas, lo más común y recomendable es que se firme el documento dejando en el mismo una copia del certificado y que el validador lo obtenga de allí, las garantías que da el esquema PKI a través de las Autoridades Certificadoras de confianza permite esta flexibilidad.

Validación de la integridad del documento

El primer paso consiste en verificar que el documento o la firma no fueron alterados en el intercambio, ya que si esta propiedad no se cumple, el resultado todos los controles subsiguientes es dudoso. Para hacerlo, se debe

  • obtener la llave pública del firmante de su certificado, y utilizarla para descifrar la firma, lo que da como resultado el hash del documento que calculó el firmante.
  • volver a calcular aparte el hash del documento recibido nuevamente. Si coincide con el hash descifrado previamente, entonces se puede estar seguro de que el documento no fue modificado por una tercera parte entre su firma y la validación, obteniendo así la garantía de identidad buscada.

Tanto las firmas como los hashes pueden ser realizados con múltiples algoritmos, aplicando transformaciones intermedias y demás. Si las dos partes no aplican las mismas transformaciones y los mismos algoritmos, los resultados de las operaciones no serán los mismos y por lo tanto no será posible verificar correctamente una firma aún cuando no se haya modificado nada efectivamente. Para esto es que los estándares de firma especifican también qué mecanismos se utilizaron en cada firma en particular, y es otro motivo por el cual siempre se recomienda utilizarlos en lugar de hacer una solución propia.

Validación de la identidad del firmante

Una vez validada la integridad del documento, lo que se sabe es que el mismo no fue modificado en tránsito y que fue firmado con el certificado que se utilizó para validar. Lo que no se sabe aún es si los datos del firmante que figuran en el certificado son ciertos, es decir, si el certificado es válido.

Para garantizar la validez de un certificado, se deben verificar cuatro propiedades: la vigencia, la autenticidad, el estado de revocación y la cadena de confianza.

Vigencia

El primer control que se debe hacer al validar cualquier certificado es la validez del mismo, ya que se emiten por un período acotado. Si la fecha de validación está fuera del rango de fechas de validez que indica el certificado, la misma ya debe fallar y no continuar.

Autenticidad

El certificado es en sí mismo un documento electrónico que contiene la llave pública del firmante y sus datos, y es firmado por una autoridad certificadora (CA) que mediante dicha firma certifica que registró correctamente al sujeto identificado en el certificado, dando fé de que esos son efectivamente sus datos y su llave pública. Se debe entonces validar la firma del certificado del firmante utilizando el certificado del emisor, es decir, de la autoridad certificadora, siguiendo el mismo procedimiento que se siguió para el documento y teniendo en cuenta que el estándar x.509 en el cual se elaboran los certificados estandariza el modo de firmarlos. Si se valida correctamente, se puede estar seguro de que el firmante pasó por el registro de esa autoridad certificadora, resultando en un certificado auténtico. Típicamente, los certificados a validar cuentan con una extensión llamada Authority Information Access, que contiene la URL de Internet donde se publica el certificado de la CA que lo emitió, y de esa forma cualquier validador puede descargarlo. Esta extensión es obligatoria para los certificados emitidos por prestadores acreditados de Uruguay, por lo que se puede asumir que estará presente cuando se validan firmas electrónicas avanzadas.

Estado de Revocación

Las CA emiten los certificados por un período de validez dado, como ya fue visto, y además una vez que son emitidos la llave privada y el certificado mismo quedan en control exclusivo del usuario final. Si este usuario incurriera en un mal uso del certificado, faltara a las condiciones de negocio acordadadas, o peor aún, su clave privada fuera comprometida por un tercero que pueda comenzar a usar el certificado en su nombre, la CA no tiene forma de eliminar esa llave privada o certificado, y es por eso que lo que sí hace es publicar uno o varios servicios de tipo "lista negra" donde se publican los certificados cuya validez fue terminada prematuramente, o dicho de otra manera, los certificados revocados.

El mecanismo más básico para consultar el estado de revocación es la CRL (Certificate Revocation List), que consiste simplemente en un archivo firmado por la CA (para garantizar su autenticidad) que contiene los números de serie de los certificados emitidos por ella que se encuentran revocados. Para verificar si un certificado dado está revocado entonces basta con obtener la CRL de la CA correspondiente, validar su firma con el certificado de la CA, y verificar si el número de serie del certificado se encuentra en la lista. Si está, se encuentra revocado, y si no lo está, no. Los certificados de usuario final además cuentan con una extensión llamada CRL Distribution Points, que contiene el o las URL de internet donde se publica la CRL de la CA, que es la que se debe consultar para ver el estado de revocación. Esta extensión es obligatoria para los certificados emitidos por prestadores acreditados de Uruguay, y además la implementación de la CRL también lo es, por lo que si bien es un método precario, en la mayoría de los escenarios es suficiente, y resulta en una validación muy sencilla de implementar.

Otro método de verificación de estado de revocación es el OCSP (Online Certificate Status Protocol), que consiste en un servicio publicado por la CA, que recibe consultas por un certificado dado a través de su número de serie, y responde un mensaje especial del protocolo indicando si se encuentra revocado, si no, o si no puede contestar en este momento. Cabe destacar que estos mensajes de respuesta son firmados por la CA o por una Autoridad de Validación de la misma para garantizar su autenticidad. OCSP es un protocolo más flexible que la CRL, y que escala mejor en escenarios donde las CA manejan muchas revocaciones, dado que evita descargar e interpretar listas largas, pero la contrapartida es que no todas las CA lo implementan (no es obligatorio) y que su implementación en validadores es más compleja que mediante CRL. Si implementa OCSP, la CA incluirá en los certificados que emita la URL de consulta de dicho servicio dentro de la extensión Authority Information Access.

Cadena de Confianza

Luego de ejecutadas las validaciones anteriores se sabe que el certificado está dentro de su período de validez, que no está revocado, y que fue emitido por una CA bien identificada. Lo que potencialmente se desconoce aún es si la CA misma es auténtica, es decir, si su certificado es válido. Para esto, se debe realizar el mismo proceso de validación sobre el certificado de la CA con el certificado de su CA emisora, en un proceso iterativo que repite los mismos pasos de validación de vigencia, autenticidad y estado de revocación. Se va así construyendo una cadena de certificados electrónicos, donde un certificado "hijo" es validado con su certificado "padre" de otra CA, hasta llegar al caso base en que se encuentra una CA que emitió su propio certificado, es decir, una CA Autofirmada, una raíz de confianza. A esta cadena verificable de certificados se le denomia Cadena de Confianza.

Un certificado raíz es de confianza sólo si se lo tiene previamente instalado en el software de validación como tal, sea porque viene de fábrica o porque . Los sistemas operativos, navegadores web, editores de PDF y sistemas similares que realizan procesamiento de certificados cuentan con sus propios stores de confianza, con las raíces que son internacionalmente reconocidas. La raíz nacional de uruguay (ACRN) se encuentra en algunos de estos stores y está en proceso de inclusión en varias más. Si se va a instalar una raíz de confianza, se debe tener mucho cuidado de que sea un certificado auténtico y de confianza, porque de lo contrario se está abriendo la puerta a que se validen cadenas de confianza fraudulentas.

En el contexto de la Firma Electrónica Avanzada, las autoridades certificadoras acreditadas son Abitab (ID Digital), El Correo y el Ministerio del Interior (Cédula Electrónica). Estas autoridades son emitidas por la Autoridad Certificadora Raíz Nacional (ACRN), que la opera AGESIC. El certificado de la ACRN puede ser descargado de http://www.agesic.gub.uy/acrn/acrn.cer


A modo de resumen, se debe realizar la siguiente cadena de validaciones:

  1. Validar firma de documento con certificado del firmante
  2. Validar certificado del firmante (vigencia, autenticidad y estado de revocación) usando certificado de AC.
  3. Validar certificado de AC (vigencia, autenticidad y estado de revocación) usando certificado de ACRN.
  4. Validar certificado de ACRN verificando que sea el mismo que se tiene instalado previamente.

Los puntos 2 al 4 conforman lo que se denominó como validación de la cadena de confianza.

4261 Accesos
Promedio (2 Votos)
archivos adjuntos