Las firmas digitales, así como los certificados que permiten su verificación, son herramientas fundamentales a la hora de otorgar validez a los documentos electrónicos. Por ello, la tecnología que viabiliza su utilización requiere de especial cuidado y atención.

Este cuidado se vincula fundamentalmente a la utilización de estándares tecnológicos basados en normas y protocolos internacionalmente aceptados.

Esto último asegura no sólo el correcto funcionamiento de Infraestructura de Firma Digital, sino también la interoperabilidad de las aplicaciones y entre Certificadores Licenciados nacionales con las infraestructuras de Claves Públicas de otros países.

Frente a cualquier transacción que involucre el uso de una firma digital o de un certificado digital, la adopción de estándares tecnológicos internacionalmente aceptados permite asegurar un proceso efectivo de verificación de dichas firmas, otorgando seguridad técnica y legal a las transacciones electrónicas.

En este marco, la Infraestructura de Firma Digital de la República Argentina (IFDRA) ha adoptado los siguientes estándares tecnológicos:

• Formato de los certificados y de las listas de certificados revocados: ITU–T X509.
• Generación de las claves: RSA, DSA o ECDSA.
• Protección de las claves privadas de certificadores y suscriptores: FIPS 140.
• Políticas de certificación: RFC 3647, 5280 y 3739.

El listado completo de los estándares aprobados para la IFDRA, así como las condiciones bajo las cuales deben ser utilizados, se encuentra descripto en la Resolución 946/2021 Anexo 4 de la Secretaría de Innovación Pública.

ITU–T RECOMMENDATION X.509 | ISO/IEC 9594–8

Tecnología de la Información – Interconexión de Sistemas Abiertos – El Directorio: Marcos para Certificados de Claves Públicas y Atributos.

Recomendación / Estándar Internacional que establece el Marco para Certificados de Clave Pública (PKI) y Certificados de Atributo (PMI). Incluye la especificación de los objetos de datos usados para representar los certificados en sí mismos, tanto como la información sobre la revocación de los emitidos, a través de la lista de los revocados. La especificación define la base fundamental desde la cual se puede construir una infraestructura de clave pública completa con sus especificaciones y algunos componentes críticos de dicha infraestructura, aunque no lo hace en su totalidad.

La Versión 3 del X.509 amplía la funcionalidad del estándar. Define las extensiones del certificado, lo cual permite que una organización pueda establecer sus propias extensiones para contener información específica de su entorno de operación, así como también las extensiones en la Lista de Certificados Revocados: CRL (por su sigla en inglés). De igual modo, define también los objetos de información para mantener los objetos PKI en el Directorio y cómo realizar la comparación entre los valores actuales y los almacenados. Igualmente, brinda los servicios de autenticación para el Directorio y los usuarios. La información almacenada en el Directorio, más conocida por su sigla en inglés: DIB (Directory Information Base/Base de Información del Directorio), es generalmente utilizada para facilitar las comunicaciones entre objetos tales como entidades–aplicaciones, terminales, personas y listas de distribución. 

Los anexos integrados a la Recomendación son los siguientes: 

Anexo A: Provee el módulo ASN.1, que contiene todas las definiciones asociadas al marco de los certificados.

Anexo B: Proporciona las reglas para generar y procesar las listas de certificados revocados.

Anexo F: Define los Identificadores de Objetos: OID (por su sigla en inglés), asignados a los algoritmos de autenticación y encriptación, en ausencia de un registro formal.

Ver estándar original en inglés

RFC 6960 – X.509 Infraestructura de Clave Pública Internet. PKI Protocolo en línea del Estado del Certificado – OCSP

(por su sigla en inglés: Online Certificate Status Protocol)

Este documento especifica el protocolo para determinar el estado actual de un certificado digital, sin requerir la lista de certificados revocados (CRL) en la infraestructura PKIX. Los mecanismos adicionales que direccionan los requerimientos operacionales no son especificados en este documento.

El Protocolo en línea de Estado del Certificado (OCSP) permite a las aplicaciones determinar el estado (revocación) de un certificado identificado. El OCSP puede ser usado para satisfacer algunos de los requerimientos operacionales de proveer en forma más oportuna la información de estado de la revocación que la que es posible con las CRL y puede ser usado para obtener información adicional del estado de un certificado. Un cliente de OCSP emite un requerimiento de estado a un servidor OCSP y supedita la aceptación del certificado hasta que el servidor OCSP le provea la respuesta.

Este protocolo especifica qué dato necesita ser intercambiado entre una aplicación que comprueba el estado de un certificado y un servidor que provee dicha información de estado.

Ver estándar original en inglés

FIPS 140-2 (Federal Information Processing Standards)

FIPS 140–2 es un estándar emitido por el NIST (National Institute of Standards and Technology), con el objetivo de establecer los requerimientos de seguridad que deben cumplir los módulos criptográficos utilizados para la protección de información sensible. Este estándar fue emitido con el fin de coordinar los requerimientos que deben ser observados por los departamentos y agencias gubernamentales de los Estados Unidos, cuando utilizan dispositivos criptográficos. FIPS es un acrónimo de ”Federal Information Processing Standard”, es decir: Estándar Federal para el Procesamiento de Información. El estándar FIPS 140–2 se refiere tanto a componentes de hardware como de software y comprende también otros aspectos, como por ejemplo, la condiciones que debe cumplir la documentación. Remplaza al FIPS 140–1, emitido previamente también por el NIST.

Hoy en día, este estándar es aceptado internacionalmente como guía para la incorporación de dispositivos criptográficos en instalaciones seguras, ya que es posible validar cada producto a través de certificados en los que se especifica el nombre exacto del módulo, el hardware, el software, la firma y los números de versión de cada componente sujeto a validación.

El estándar mencionado propone un esquema incremental de exigencias de seguridad, basado en 4 niveles que cubren una amplia gama de aplicaciones y ambientes en los que se emplean módulos criptográficos. Estas exigencias resguardan áreas vinculadas al diseño seguro y la implementación adecuada de un módulo criptográfico y abarcan aspectos tales como especificaciones técnicas, características de los puertos e interfaces, roles y servicios, mecanismos de autenticación, condiciones de seguridad física y del ambiente operacional y aspectos vinculados a la gestión de claves criptográficas, la compatibilidad y la protección contra interferencias electromagnéticas, así como autoevaluaciones y cuestiones vinculadas a la mitigación de otros ataques. Los requisitos exigidos para cada nivel se suman a los correspondientes del anterior.

Los cuatro niveles establecidos por el estándar FIPS 140–2 contienen las siguientes prescripciones:

• FIPS 140–2 nivel 1: es el de menor exigencia ya que impone una serie acotada de requerimientos. No establece estipulaciones específicas respecto a los mecanismos de seguridad física, más allá de un mínimo de condiciones vinculadas al proceso de producción. Permite que los componentes de software y el firmware sean ejecutados en un sistema de propósito general que emplea un sistema operativo no evaluado. La utilización de un dispositivo que alcanza este nivel se aconseja sólo cuando no existen otros controles, tales como los físicos, los de red y los administrativos, o cuando éstos sean muy limitados.

• FIPS 140–2 nivel 2: agrega requerimientos en materia de seguridad, entre los cuales se encuentran la inclusión de instancias que permitan la generación de evidencia frente a manipulaciones y la autenticación, en base a roles previamente asignados. En este último caso, el módulo criptográfico debe verificar la autorización de un operador para asumir un rol específico y acceder a un determinado conjunto de servicios. En este nivel se permite que los componentes de software y firmware sean ejecutados sobre una instalación que emplea un sistema operativo acorde con los perfiles de protección de la norma ISO/IEC 15408 (también conocida como “Common Criteria”), que hayan sido evaluados como nivel EAL 2 o superior.

• FIPS 140–2 nivel 3: incorpora mecanismos para la prevención de intrusiones, con el fin de evitar el acceso no autorizado al módulo criptográfico y de responder ante estos intentos. Tales mecanismos incluyen entre otros, el uso de circuitos de detección de tentativas de manipulación que apunten a “zeroizar ” (1) componentes cuando se intenta abrir o manipular el dispositivo. En cuanto a los mecanismos de autenticación, éstos se basan en la identidad, incrementando los requisitos establecidos para el nivel 2. En este nivel, se realiza la autenticación de la identidad de un operador y luego se verifica que se encuentre autorizado a asumir un rol determinado y a utilizar una serie de servicios. En cuanto al software y firmware, en este nivel se requiere que los sistemas operativos tengan un nivel EAL 3 o superior, con requerimientos adicionales de seguridad.

• FIPS 140–2 nivel 4: contiene las mayores exigencias definidas en este estándar. Los mecanismos de seguridad se plantean como un esquema de protección completa sobre el módulo criptográfico, con el objetivo de permitir la detección y respuesta ante cualquier intento de acceso físico no autorizado. Todo acceso no autorizado tiene como consecuencia la "zeroización” de los parámetros de seguridad críticos. Los módulos criptográficos que cumplen con las exigencias de este nivel son utilizados generalmente en ambientes que carecen de mecanismos adecuados de protección. Por este motivo, se prevén mecanismos de aseguramiento frente a condiciones ambientales adversas y fluctuaciones que superen los niveles operativos normales de voltaje y temperatura. En cuanto a los componentes de hardware y software, pueden ser ejecutados en un sistema que cumpla con los requerimientos del nivel 3 y tenga una evaluación EAL4 o superior. 

(1) La zeroización es un método de borrado o destrucción de la información almacenada en formato electrónico, basado en la alteración o eliminación de los contenidos, de manera tal que no sea posible su recuperación.

Ver estándar original en inglés