Uno de los grandes inconvenientes que se plantean cuando utilizamos documentos electrónicos, es
determinar su autenticidad, esto es resuelto por la Firma Digital (FD), que se basa en procedimientos criptográficos (textos transformados mediante
técnicas criptográficas, el cual resulta ilegible, a menos que se cuente con
una clave).
La FD es similar a la firma de puño y letra en los documentos impresos, lo
cual permite atribuir a una persona su conformidad en un documento.
El sistema de FD consta de dos partes:
-
Un método que haga imposible la alteración de la firma
-
Y otro que permita verificar que la firma pertenece al firmante.
Para ellos se debe generar una Clave
Publica (CPl) y una Clave Privada (CPr),
la primera de ellas debe ser conocida por todos, mientras que la segunda es
solo de uso y conocimiento del usuario.
Su generación siempre es pareja y están relacionadas entre sí, así es que
todo lo que sea encriptado (proceso
que transforma un texto plano o documento en un criptograma) por una de ellas
solo podrá ser desencriptado (proceso
que recupera el texto plano o documento de un criptograma) por la otra.
Existen diversas formas de almacenar una CPr, en un archivo en el disco rígido
de la PC o en una tarjeta inteligente (smartcard, pen drive, etc).
Es asi que el firmante genera mediante una función matemática una Huella Digital (HD) – conocida como Función Hash o resumen de mensaje-, por la cual se obtiene una serie moderada
corta de caracteres, que representan el texto al cual se le aplica esta función
hash, y debe ser una función unidireccional para que el mensaje original no
pueda ser recuperado a partir del hash, si existiera una manera de encontrar el
texto plano o documento sin incriptar desde el hash, se diría que la función
presenta una trapdoor (puertas
trampa o trasera).
La creación de la FD se lleva a cabo a través de un algoritmo (conjunto de
instrucciones o reglas definidas y finitas que permite realizar una actividad
mediante pasos sucesivos que no generan dudas a quien las debe realizar) que
combina los caracteres que conforman la CPr con los caracteres del documento.
De este modo se obtiene la FD y juntos el documento y la FD conforman el documento firmado.
Entonces
decimos que una “FD es un conjunto de datos asociados a un mensaje que permite
asegurar la identidad del firmante y la integridad del mensaje”.
De esta
manera el firmante va a estar adjuntando al documento una marca que es única
para ese documento y que sólo él es capaz de producir.
Todas las FD
generadas por una persona son diferentes entre sí, porque la FD cambia con cada
documento firmado. Si dos personas firman un mismo documento, también se
generan dos diferentes documentos firmados, porque la CPr utilizada es
diferente.
El receptor
del mensaje podrá comprobar que el mensaje no fue modificado desde su creación
y que el firmante es quién dice serlo a través del siguiente procedimiento:
En primer
término generará la Huella Digital o Hash del mensaje recibido, luego
desencriptará la FD del mensaje, utilizando la CPl del firmante y
obtendrá de esa forma la Huella Digital o Hash del mensaje original; si ambas Huellas
Digitales coinciden, significa que el mensaje no fue alterado y que el firmante
es quien dice serlo.
Si el
documento o la firma es modificada, aunque sea ligeramente, el procedimiento de
autenticación indicara que el documento firmado no es autentico.
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.
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.
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.
Decreto 901/2009
Resolución Nº 62/2008
Decisión Administrativa JGM Nº 06/2007
Resolución SGP N° 63/2007
Resolución SGP N° 64/2007
Decreto N° 724/2006
Resolución JGM Nº 435/2004
Decreto Nº 160/2004
Resolución JGM Nº 20/2004
Decreto Nº 1028/2003
Decreto Nº 624/2003
Decreto Nº 283/2003
Decreto Nº 2628/2002
Disposición ONTI 05/2002
Decreto Nº 1023/2001
Decreto 889/01 Art. 7º
CERTIFICADO DIGITAL
En el
proceso de autenticar un documento con FD, mencionamos que el receptor debe
contar con un archivo donde contenga la CPl del supuesto firmante, pero que
sucede cuando esa persona debe autenticar un documento firmado por más de una
persona, por ejemplo10 personas o más, deberá contar con 10 archivos o más?.En
general se procede a la confección de una base de datos de los posibles firmantes,
pero si el numero de firmantes crece desconsiderablemente también crece el
número de usuarios de CPl , lo cual es
solucionado mediante el Certificado
Digital (CD).
Los certificados son emitidos por el Certificador
Licenciado (persona de existencia ideal que cuenta con una licencia para
ellos, otorgada por el Ente Licenciante Art. 17 de LFD).
Los CD son
documentos digitales que dan fe de la vinculación entre una CPl y un
individuo o entidad. Permiten verificar que una CPl específica pertenece,
efectivamente, a un individuo determinado.
Contienen la
identidad de la persona (nombre), su CPl y el nombre de la Autoridad de Certificación (AC), todos estos datos, son previamente
validados por la AC, asegurando de esta forma la veracidad de la información.
El formato de los certificados está definido por el estándar internacional ITU-T X.509. De esta forma, los
certificados pueden ser leídos o escritos por cualquier aplicación que cumpla
con el mencionado estándar.
Los
certificados ayudan a prevenir que alguien utilice una clave para hacerse pasar
por otra persona. En algunos casos, puede ser necesario crear una cadena
de certificados, cada uno certificando el previo, para que las partes
involucradas confíen en la identidad en cuestión.
Si un sujeto firma un documento y
anexa su certificado digital, cualquiera que conozca la CPl de la AC podrá
autenticar el documento.
Se recomienda que los CD tengan
un período de validez, luego del cual deberán ser renovados.
Para obtener un CD, se deben
generar las dos claves (CPl y CPr), para ello el sujeto utiliza un programa
especial en su PC, las dos claves son números, relacionados matemáticamente
entre sí, que se general a la vez.
La
generación del par de claves se hace una sola vez. Con un par de claves se
puede firmar y verificar tantos documentos como se desee. La vida útil de un
par de claves se extiende en general por varios meses o años, según sus
características particulares.
Conociendo
esa CPl, la Autoridad Certificante, luego de identificar a la persona o
entidad, emite un certificado de clave pública a su favor.
Una de las
consecuencias de la utilización de este sistema es que la Autoridad
Certificante pasa a ser un eslabón
esencial para brindar seguridad, y como tal, la comunidad decidirá
depositar o no su confianza en una Autoridad Certificante en función de la
percepción que tenga sobre la confiabilidad de esa particular institución.
Puede suceder que en algún momento
el titular de una CPl no desee usar mas
la FD, o haya extraviado el soporte en el cual la tenía guardada su CPr. Por lo
cual debe generar la Revocación del
CD y para ello debe contar con un archivo, directorio o base de datos que
contenga los Certificados revocados y por cada uno de ellos la fecha y hora en
la que fueron revocados, que se conoce como
Lista de Certificados Revocados
(CRL siglas en ingles).
Un CRL es un archivo firmado por
la AC, que contiene la fecha de emisión del CRL y una lista de certificados
revocados, cada uno de ellos con la fecha de revocación.
Un CRL puede ser autenticado como
cualquier otro documento firmado digitalmente, en este caso con la CPl de la
AC, una vez autenticado, podemos confiar en su veracidad y determinar con certeza
si un certificado esta revocado o no, esto es hasta la fecha definida por Ultima
Actualización.
Algunos de
los certificados más comunes son:
· Personales: identifican
a personas físicas o jurídicas.
· Autenticación de servidor: identifican a un servidor que pertenece a una
persona.
· Firma de software: identifican al autor de una pieza de software.
Los Certificadores Licenciados, certifican la autenticidad
de la CPl en régimen de libre competencia, equilibrio de participación y
protección de los usuarios (Art.11 Dec.Reg.)
Pueden ser:
- Empresas
respecto de sus empleadores,
- Bancos
respecto de sus clientes,
- Colegio de
Abogados respectos de los matriculados, Academias de Medicina,etc.
En nuestro país la FD se
encuentra regulada mediante la norma 25.506 y su Dec. Reg. 2628/2002.
Por lo cual la FD no es solo
tecnología, sino también derecho, es así que se dice que la FD es un instrumento con características
técnicas y normativas, lo que significa que existen procedimientos técnicos que
permiten la creación y verificación de FD y existen documentos normativos que
respaldan el valor legal que dichas firmas poseen, como la Infraestructura de
Firma Digital de la República Argentina y la ONTI.
La ley Argentina reconoce dos
tipos de FD y la diferencia entre ambas se encuentra en su base jurídica.
·La FD,
definida como el resultado de aplicar a un documento digital un procedimiento
matemático, requiere información de exclusivo conocimiento del firmante,
encontrándose ésta bajo su absoluto control. Pero, dado que la misma ley
estipula que para asegurarse de que el firmante es el único que conoce y
controla el procedimiento matemático, se debe cumplir con una serie de recaudos
legales; la firma digital puede ser caracterizada por medio de la
siguiente fórmula:
FD=documento digital+procedimiento matemático+requisitos legales.
|
·La firma
electrónica, en cambio, es definida en términos negativos como
el conjunto de datos electrónicos integrados, ligados o asociados de manera
lógica a otros datos electrónicos, utilizado por el signatario como su medio de
identificación, que carezca de alguno de los requisitos legales para ser
considerada firma digital. La fórmula, en este caso, es la siguiente:
|
Firma electrónica = firma digital – requisitos
legales.
|
Esta
diferencia en cuanto a los requisitos repercute en los efectos asignados a cada
una:
La FD:
a) Equivale a la firma manuscrita,
b) Se presume que la firma pertenece al titular del certificado digital,
c) Se presume que el documento no ha sido modificado luego de la firma.
a) Equivale a la firma manuscrita,
b) Se presume que la firma pertenece al titular del certificado digital,
c) Se presume que el documento no ha sido modificado luego de la firma.
Firma
electrónica:
a) En caso
de ser desconocida corresponde a quien la invoca acreditar su validez.
APLICACIONES
de casos particulares a nivel mundial:
·Transacciones
bancarias
·Transacciones
comerciales
·Declaraciones
impositivas
·Documento de
identidad electrónico (e-DNI)
·Voto
electrónico
·Certificación
de los actos de gobierno (leyes, resoluciones, dictámenes, sentencias,
etcétera)
·Contrataciones
públicas (envío y recepción de ofertas, adjudicaciones, etcétera)
·Documentos
relativos a operaciones de seguro
·Historias
clínicas
·Obtención
del CUIL
·Solicitud de
empleo público
Es necesario
tener en cuenta que la ley de FD argentina, excluye del ámbito de aplicación de
la FD a los actos relacionados con disposiciones por causa de muerte, el
derecho de familia, personalísimos que deban ser instrumentados bajo exigencias
o formalidades incompatibles con la utilización de la firma digital, por
expresa disposición legal o en virtud de acuerdo de las partes interesadas.
Ventajas y Desventajas:
Las ventajas derivadas de la utilización del
sistema de FD van desde el aumento
de la seguridad en las
transacciones hasta la no
necesidad de presencia o traslado físico, ventajas éstas que se
traducen en celeridad y ahorro
de costos.
Entre las desventajas podemos mencionar la necesidad de contar con una autoridad certificadora de confianza (tercera parte de confianza) y la responsabilidad que pesa sobre los propios usuarios de generar un entorno adecuado que les permita mantener bajo su exclusivo control los datos de creación de la firma y contar con un dispositivo de creación técnicamente confiable.
Entre las desventajas podemos mencionar la necesidad de contar con una autoridad certificadora de confianza (tercera parte de confianza) y la responsabilidad que pesa sobre los propios usuarios de generar un entorno adecuado que les permita mantener bajo su exclusivo control los datos de creación de la firma y contar con un dispositivo de creación técnicamente confiable.
Estándares tecnológicos:
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:
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:
Para el formato de los
certificados y de las listas de certificados revocados: ITU–T X509.
• Para la generación de las claves: RSA, DSA o ECDSA.
• Para la protección de las claves privadas de certificadores y suscriptores: FIPS 140.
• Para las políticas de certificación: RFC 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 Decisión Administrativa Nº 6/2007 (Anexo 3).
• Para la generación de las claves: RSA, DSA o ECDSA.
• Para la protección de las claves privadas de certificadores y suscriptores: FIPS 140.
• Para las políticas de certificación: RFC 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 Decisión Administrativa Nº 6/2007 (Anexo 3).
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.
RFC 2560 – 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.
FIPS 140
(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.
Ente
Licenciante:
La Infraestructura de Firma Digital de la
República Argentina (IFDRA) está conformada por un conjunto de
componentes que interactúan entre sí, permitiendo la emisión de certificados
digitales para verificar firmas digitales en condiciones seguras, tanto desde
el punto de vista técnico como legal.
La Secretaría de Gabinete
actúa como Ente Licenciante otorgando, denegando o revocando las
licencias de los certificadores licenciados y supervisando su accionar.
En este sentido, los certificadores licenciados son entidades públicas o privadas que se encuentran habilitados por el Ente Licenciante para emitir certificados digitales, en el marco de la Ley 25.506 de Firma Digital.
Para la obtención de la licencia, un certificador debe cumplir con los siguientes pasos:
• Inicio del trámite
Presentación de la solicitud conjuntamente con toda la documentación detallada en Anexo I de la Decisión Administrativa Nº06/2007.
• Admisibilidad de la solicitud
Estudio de forma, mediante la verificación de la documentación presentada.
• Análisis de la documentación
Estudio detallado de toda la documentación para determinar el cumplimiento de los requisitos necesarios para funcionar como certificador licenciado.
• Auditoría de conformidad
Evaluación del ambiente de controles de las instalaciones y verificación del cumplimiento de los requisitos técnicos y legales.
• Dictamen de aptitud
Emisión del dictamen legal y técnico correspondiente, recomendando al Ente Licenciante el otorgamiento o la denegación de la licencia.
• Otorgamiento de la licencia
Dictado de la resolución por parte de la Secretaría de Gabinete que otorga o rechaza la licencia.
• Certificado digital del certificador
Emisión de un certificado digital a nombre del certificador por parte de la Autoridad Certificante Raíz.
• Inicio de las operaciones del certificador licenciado
A partir de la emisión de su certificado digital, el certificador licenciando podrá emitir certificados digitales a personas físicas, jurídicas o aplicaciones, en el marco de la política de certificación aprobada.
En este sentido, los certificadores licenciados son entidades públicas o privadas que se encuentran habilitados por el Ente Licenciante para emitir certificados digitales, en el marco de la Ley 25.506 de Firma Digital.
Para la obtención de la licencia, un certificador debe cumplir con los siguientes pasos:
• Inicio del trámite
Presentación de la solicitud conjuntamente con toda la documentación detallada en Anexo I de la Decisión Administrativa Nº06/2007.
• Admisibilidad de la solicitud
Estudio de forma, mediante la verificación de la documentación presentada.
• Análisis de la documentación
Estudio detallado de toda la documentación para determinar el cumplimiento de los requisitos necesarios para funcionar como certificador licenciado.
• Auditoría de conformidad
Evaluación del ambiente de controles de las instalaciones y verificación del cumplimiento de los requisitos técnicos y legales.
• Dictamen de aptitud
Emisión del dictamen legal y técnico correspondiente, recomendando al Ente Licenciante el otorgamiento o la denegación de la licencia.
• Otorgamiento de la licencia
Dictado de la resolución por parte de la Secretaría de Gabinete que otorga o rechaza la licencia.
• Certificado digital del certificador
Emisión de un certificado digital a nombre del certificador por parte de la Autoridad Certificante Raíz.
• Inicio de las operaciones del certificador licenciado
A partir de la emisión de su certificado digital, el certificador licenciando podrá emitir certificados digitales a personas físicas, jurídicas o aplicaciones, en el marco de la política de certificación aprobada.
Certificadores Licenciados:
AFIP – Administración Federal de Ingresos Públicos. Ir al sitio >
ANSES – Administración Nacional de la Seguridad Social. Ir al sitio >
ONTI – Oficina Nacional de Tecnologías de Información.
ANSES – Administración Nacional de la Seguridad Social. Ir al sitio >
ONTI – Oficina Nacional de Tecnologías de Información.
Normativa
Aplicable:
Ley Nº 25.506
·
Ley de Firma Digital, publicada en el Boletín Oficial el 14/12/2001.
Decreto 901/2009
·
Aprueba la nueva estructura
organizativa de la Jefatura de Gabinete de Ministros y en particular, la de la
Secretaría de la Gestión Pública. En su punto Nº 21 establece la competencia de
la Secretaría para actuar como autoridad de aplicación del Régimen Normativo de
la Infraestructura de Firma Digital (Ley Nº 25.506), como así también, en las
funciones de ente licenciante de certificadores, supervisando su accionar.
Entre los objetivos de la nueva Subsecretaría de Tecnologías de Gestión,
establece su función de Autoridad Certificante de Firma Digital para el Sector
Público Nacional.
Resolución Nº 62/2008
·
Determina que la ONTI, con el concurso de la Dirección de
Infraestructura y de Recursos Informáticos, emitirá el dictamen legal y técnico
previo al licenciamiento de certificadores.
Decisión Administrativa JGM Nº 06/2007
·
Establece el marco normativo de firma digital aplicable al
otorgamiento y revocación de las licencias a los certificadores que así lo
soliciten.
Resolución SGP N° 63/2007
·
Política de Certificación de la
Autoridad Certificante Raíz de la República Argentina.
Resolución SGP N° 64/2007
·
Procedimientos operativos para la
instalación y puesta en marcha de la Autoridad Certificante Raíz de la
República Argentina.
Decreto N° 724/2006
·
Modifica el Decreto N° 2628/02
reglamentario de la Ley de Firma Digital.
Resolución JGM Nº 435/2004
·
Aprueba el Reglamento de funcionamiento de la Comisión
Asesora para la Infraestructura de Firma Digital, que fuera creada por la Ley
N° 25.506 y cuyos miembros fueran designados por Decreto N° 160/04 del Poder
Ejecutivo Nacional.
Decreto Nº 160/2004
·
Designa a los integrantes de la
Comisión Asesora para la Infraestructura Nacional de Firma Digital, en
cumplimiento de lo dispuesto en la Ley N° 25.506, los cargos duran, conforme al
Artículo 35 de la ley referida, 5 años y son renovables.
Resolución JGM Nº 20/2004
·
Asigna a la DIRECCIÓN DE
APLICACIONES dependiente de la OFICINA NACIONAL DE TECNOLOGÍAS DE INFORMACIÓN
la acción de asistir al Director de la Oficina en el cumplimiento de las
obligaciones y funciones establecidas en los Artículos 13 y 14 del Decreto Nº
2628/2002, entre las cuales se encuentra la auditoría necesaria para el licenciamiento
prevista en las normas técnicas de firma digital aprobadas por la Decisión
Administrativa Nº 06/07. Esta norma está modificada por el Decreto 624/03.
Decreto Nº 1028/2003
·
Disuelve el Ente Administrador de
Firma Digital, creado por el Artículo 11 del Decreto N° 2628/02, cuyo accionar
será llevado a cabo por la Oficina Nacional de Tecnologías de Información de la
Subsecretaría de la Gestión Pública. MODIFICATORIO del Decreto 624/03.
Decreto Nº 624/2003
·
Aprueba la estructura organizativa
de primer nivel operativo de la Jefatura de Gabinete de Ministros.
Decreto Nº 283/2003
·
Autoriza con carácter transitorio a
la Oficina Nacional de Tecnologías de Información a proveer certificados
digitales para su utilización en aquellos circuitos de la Administración
Pública Nacional que requieran firma digital, de acuerdo con la política de
certificación vigente.
Decreto Nº 2628/2002
·
Reglamenta la Ley N° 25.506 de
Firma Digital y crea el Ente Administrador de Firmas Digitales.
Disposición ONTI 05/2002
·
Aprueba la "Política de
Certificación de la ONTI: Criterios para el otorgamiento de certificados a
favor de suscriptores", el "Manual de Procedimientos", el
"Plan de Cese de Actividades" y la "Política de Seguridad"
para la Autoridad Certificante de la Oficina Nacional de Tecnologías
Informáticas.
Decreto Nº 1023/2001
·
Contempla en su artículo 21 la realización de las
contrataciones comprendidas en el Régimen de Contrataciones de la
Administración Pública en "formato digital firmado digitalmente".
Decreto 889/01 Art. 7º
·Aprueba la estructura organizativa de la SECRETARÍA PARA LA
MODERNIZACIÓN DEL ESTADO de la JEFATURA DE GABINETE DE MINISTROS: organigrama,
responsabilidades primarias y acciones y dotación. Aprueba aperturas
inferiores. En anexo I crea la ONTI y en el II explicita su responsabilidad
primaria y acciones. Vigente en cuanto a la creación de la ONTI, no respecto de
las competencias.
