Guía de Acreditación de Aplicaciones de Software

Programa de Modernización y Descentralización del
Estado de la República Del Perú.
Oficina Nacional de Gobierno Electrónico e Informática
Guía de Acreditación de
Aplicaciones de Software
Requerimientos para acreditar una
aplicación (SW) de Clave Pública (PK)
Versión 3.4
Consultor Piloto – Guía de Acreditación de
Aplicaciones de Software
-1-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
1. Unidad: Unidad Co Ejecutora PCM (UCE PCM)
2. Componente: Gobierno Electrónico
3. Línea Presupuestal (seguir código POA): 21310305
4. Nombre de Actividad y/o Servicio: Consultor Piloto – Guía de
Acreditación
5. Funcionario Responsable de la Supervisión: El Especialista en
Gobierno Electrónico de la UCE-PCM y el Jefe de la Oficina Nacional
de Gobierno Electrónico e Informática.
-2-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
ÍNDICE GENERAL
1.
INTRODUCCIÓN .................................................................................................................... 5
1.1
1.2
1.3
1.4
1.5
PROPÓSITO ........................................................................................................................... 5
DE LAS APLICACIONES (SOFTWARE) DE FIRMA DIGITAL ................................................. 6
DE LOS SISTEMAS DE INTERMEDIACIÓN DIGITALES ........................................................ 7
PÚBLICO AL QUE VA DIRIGIDO .......................................................................................... 10
VISIÓN GENERAL ............................................................................................................... 10
2.0
ANTECEDENTES .............................................................................................................. 19
3.0
DOCUMENTOS APLICABLES Y ALCANCES........................................................ 31
3.1
3.2
4.0
DOCUMENTOS APLICABLES ............................................................................................... 31
NIVELES DE SEGURIDAD DE PKI...................................................................................... 33
REQUERIMIENTOS ........................................................................................................ 35
4.1
REQUERIMIENTOS GENERALES.......................................................................................... 35
4.1.1
Automatización preferente de los Procedimientos ................................. 35
4.1.2
Uso de Módulos Criptográficos Evaluados ................................................. 35
4.1.3
Seguridad del computador .............................................................................. 36
4.2
REQUERIMIENTOS ESPECÍFICOS ....................................................................................... 36
4.2.1
Manejo de Claves ................................................................................................ 37
4.2.1.1
Generación de Par de Claves .....................................................37
4.2.1.2
Almacenamiento de Clave y Certificados Relacionados ........ c 38
4.2.1.3
Procesamiento de Entidades Acreditadas en la TSL.................39
4.2.1.4
Recuperación de Información.....................................................39
4.2.1.5
Importación y Exportación de Claves ........................................39
4.2.2
Interfaz PKI ........................................................................................................... 39
4.2.2.1
Protocolos de Comunicación .........................................................39
4.2.2.2
Solicitud y Obtención de Nuevos Certificados para Suscriptores .39
4.2.2.3
Recuperación de Certificados .......................................................40
Servicios de Cifrado ........................................................................................... 40
4.2.3
4.2.3.1
Servicios Asimétricos ....................................................................40
4.2.3.2
Servicios Simétricos ......................................................................41
4.2.3.3
Servicios de Resumen...................................................................41
4.2.3.4
Generadores de Número Aleatorios ..............................................41
Verificación del Estado del Certificado ........................................................ 42
4.2.4
4.2.4.1
Procesamiento de las CRLs ..........................................................43
4.2.4.2
Verificación del estado del Certificado mediante respondedor
OCSP
43
4.2.4.3
Desarrollo de la Ruta y Procesamiento de la Ruta de la TSL .......43
4.3
4.4
4.5
4.2.4.3.1
Desarrollo de la Ruta.................................................................. 44
4.2.4.3.2
Procesamiento de la Ruta........................................................... 44
4.2.4.4
Verificación del Estado de Revocación de un Certificado................... 44
4.2.4.5
Procesamiento de la Extensión.......................................................... 45
CONFIGURACIÓN DE LA APLICACIÓN ................................................................................ 46
DE LOS SISTEMAS DE INTERMEDIACIÓN DIGITALES ...................................................... 47
DOCUMENTACIÓN DE LA APLICACIÓN ............................................................................... 47
-3-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
5.0
5.1
5.2
5.3
Rev: 05/04-02-2008
Aprobado:
REQUISITOS DE CALIFICACIÓN ................................................................................... 49
MÉTODOS DE VERIFICACIÓN ............................................................................................. 49
VERIFICACIÓN DE INTEROPERABILIDAD ........................................................................... 49
VERIFICACIÓN DE LA SEGURIDAD..................................................................................... 55
ANEXO A: .......................................................................................................................................... 56
FORMULARIOS DE EVALUCIÓN DE LA APLICACIÓN DE SOFTWARE. ............ 56
-4-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
1. Introducción
Este documento describe los requerimientos que permiten que las
aplicaciones de software empleen la tecnología de clave pública
(Public Key, PK) e interactúen con la Infraestructura de Clave
Pública (Public Key Infraestructura, PKI) establecida por la
Infraestructura Oficial de Firma Electrónica (IOFE) de la República
del Perú, cuya Autoridad Administrativa Competente es el Instituto
Nacional de Defensa de la Competencia y de la Propiedad
Intelectual: INDECOPI.
La tecnología de clave pública es aquélla que permite proveer la
seguridad tecnológica –además, bajo el amparo de la IOFE, la
seguridad jurídica– para desarrollar entornos digitales (paperless)
que descansan sobre un marco legal que otorga seguridad a las
transacciones electrónicas. Las aplicaciones primordiales involucran
comunicaciones o traslado de información sobre redes de
comunicaciones o computacionales y permiten la comunicación
segura entre las partes.
La presente guía es parte de un conjunto de regulaciones
establecidas por Ley, y en el marco de la IOFE garantiza que los
actos jurídicos realizados con el uso de esta tecnología tengan plena
validez y eficacia jurídica, esto es, que la manifestación de voluntad
realizada a través de medios electrónicos tenga idénticas
consecuencias que aquélla realizada en forma manual (en papel
físico) y, además, cualquier relación jurídica que se desplace entre
ambos espacios tenga los mismos efectos legales.
1.1 Propósito
El propósito de este documento es establecer los requerimientos
mínimos necesarios para lograr la interoperabilidad de las
aplicaciones de software –en adelante aplicaciones– dentro del
marco de la IOFE y establecer el nivel de seguridad que permita la
protección efectiva de las funciones y objetos criptográficos (por
ejemplo, las claves de cifrado) que soporta la aplicación.
Las organizaciones que empleen la tecnología de clave pública bajo
el marco de la IOFE deben considerar los requerimientos aquí
expuestos como criterio para la selección de los productos
comerciales acreditados o incluir los requerimientos dentro de los
términos de referencia para fines de desarrollo y adquisición de
aplicaciones acreditadas para clave pública dentro del marco de la
IOFE.
-5-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
1.2 De las Aplicaciones (software) de Firma Digital
El principio básico para el no repudio de los documentos
electrónicos es que éstos se encuentren firmados digitalmente “bajo
el marco de la IOFE”. Todo documento firmado digitalmente es
considerado no repudiable de manera individual, es decir, el
principio del no repudio es aplicable al documento cuya firma digital
le corresponde.
Es necesario hacer esta redundante aclaración pues, en casos como
los documentos previamente comprimidos y cuyo archivo resultado
de la compresión es firmado digitalmente, el principio del no
repudio es únicamente aplicable al archivo comprimido firmado,
mas no a cada uno de los archivos en él contenidos. Del mismo
modo, si un correo electrónico que contiene archivos adjuntos es
firmado digitalmente –formato s-mime–, se debe observar que
adicionalmente cada archivo adjunto sea firmado digitalmente de
modo individual. En caso contrario, el principio del no repudio es
aplicable al correo y los adjuntos en conjunto, empero si alguno de
los archivos adjuntos es individualmente extraído y no se encuentra
firmado digitalmente de modo individual, el principio del no repudio
no le es aplicable.
Las aplicaciones de firma digital deben permitir la realización de
múltiples firmas digitales (cosign) en el mismo documento
electrónico, de manera recurrente. Deben de cumplir con las
normas establecidas por la IOFE, los estándares internacionales y,
de ser el caso, las normas referidas a la generación de Microformas
establecidas por el INDECOPI (Norma Técnica Peruana), y antes de
realizar el proceso de firma, deben de:
a. Constatar que el certificado sirva para el fin especificado
(firma digital, autenticación o cifrado).
b. Constatar la validez del certificado –su vigencia– antes de
proceder a la firma digital (mediante algún mecanismo OCSP,
CRL, u otro estandarizado).
c. Establecer la acreditación del certificado digital, esto es que la
EC emisora se encuentre acreditada ante la AAC (mediante
uso de la TSL ETSI TS102.231).
Las aplicaciones deberán almacenar los resultados de las
constataciones a), b) y c) en los campos respectivos e incluirlos
como extensiones del documento y firmarlos digitalmente como
parte del documento principal.
-6-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Opcionalmente, las aplicaciones pueden:
d. Incorporar la razón por la que se firma el documento.
e. Permitir la declaración de la ubicación física del firmante.
f. Incorporar un comentario (campo adicional).
g. Incorporar la rúbrica digitalizada de la firma manuscrita.
h. Otros.
Sólo si estas validaciones son satisfactorias se debe proceder a
realizar el proceso de firma. Adicionalmente, se puede agregar la
hora y fecha cierta, conforme al estándar Time Stamping RFC 3628
y el Time-Stamp Protocol (TSP) RFC 3161.
1.3 De los Sistemas de Intermediación Digital
Las principales leyes aplicables a la manifestación de la voluntad
(cualquier procedimiento administrativo, contractual, etc.) son el
Código Civil, la Ley del Procedimiento Administrativo General1 y la
Ley que Regula el Proceso Contencioso Administrativo2; regulando
como leyes informáticas específicas la Ley de Firmas y Certificados
Digitales3, su Reglamento4 donde se hace la especificación a los
Servicios de Intermediación Digitales y el Decreto Legislativo Nº
681 o Norma de Microformas Digitales.
Con respecto a los procesos de mayor importancia para el gobierno
electrónico y comercio electrónico –las contrataciones por medios
electrónicos–, estos contratos celebrados por medios informáticos
son formalmente válidos según Ley Nº 272915. Es imprescindible
cumplir con los procedimientos y formalidades establecidos en estas
leyes en el ámbito de la actuación administrativa electrónica, tanto
para cualquier actuación y tramitación como para el archivamiento
de estas actuaciones y trámites, los que deben asegurar la
1
Ley 27444
Ley 27584
3
Ley 27269
4
D.S. Nº 004-2007-PCM (Reglamento).
5
Ley que modifica el Código Civil permitiendo la utilización de los medios electrónicos para la
comunicación de la manifestación de voluntad y la utilización de la firma electrónica. Dicha ley ha
establecido lo siguiente:
“Artículo 141.- Manifestación de voluntad
La manifestación de voluntad puede ser expresa o tácita. Es expresa cuando se realiza en
forma oral o escrita, a través de cualquier medio directo,
manual, mecánico, electrónico u
otro análogo. Es tácita cuando la voluntad se infiere indubitablemente de una actitud o de
circunstancias de comportamiento que revelan su existencia. (……)”
“Artículo 141-A.- Formalidad
En los casos en que la ley establezca que la manifestación de voluntad deba hacerse a través de
alguna formalidad expresa o requiera de firma, ésta podrá ser generada o comunicada a través
de medios electrónicos, ópticos o cualquier otro análogo.
Tratándose de instrumentos públicos, la autoridad competente deberá dejar constancia del
medio empleado y conservar una versión íntegra para su ulterior consulta."
2
-7-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
autenticidad,
integridad
y
disponibilidad6
de
toda
esta
documentación electrónica para así constituirse como medio de
prueba7.
El Código Civil recoge en el artículo 13528 el principio de
consensualidad donde los contratos se perfeccionan por el
consentimiento de las partes, excepto aquellos que, además, deben
señalar la forma observada por la ley bajo sanción de nulidad.
Dispositivo que se complementa con el artículo 14119, que
establece la forma como requisito para la validez del acto, en caso
de incumplimiento lo sanciona también con nulidad.
En los contratos por medios informáticos, el contrato podrá ser
juzgado como celebrado entre ausentes o presentes según las
circunstancias del caso. Así, si el contrato se concreta por
operaciones en línea –on line– (comunicación interactiva o
simultánea), se entenderá que es un contrato entre presentes pues
la aceptación es inmediatamente conocida; en cambio, será entre
ausentes si la aceptación no es emitida en línea o requiere de una
confirmación por el oferente posteriormente enviada por otro medio
(sea fax, teléfono o documento electrónico).
6
La legislación peruana recoge el término “conservación de mensaje de datos o documentos
electrónicos” en el Artículo 8º del Decreto Supremo Nº 004-2007-PCM, Reglamento de la Ley de
Firmas y Certificados Digitales, en los siguientes términos:
Artículo 8º.- Conservación de mensaje de datos o documentos electrónicos
Cuando los documentos, registros o informaciones requieran de una formalidad adicional
para la conservación de mensajes de datos o documentos electrónicos firmados
electrónicamente, deberán:
a) Ser accesibles para su posterior consulta.
b) Ser conservados con su formato original de generación, envío, recepción u otro formato
que reproduzca en forma demostrable la exactitud e integridad del contenido electrónico.
c) Ser conservado todo dato que permita determinar el origen, destino, fecha y hora del
envío y recepción.
7
Se establece en el Artículo 6º del Decreto Supremo Nº 004-2007-PCM, Reglamento de la Ley de
Firmas y Certificados Digitales:
Artículo 6º.- Documentos Firmados Electrónicamente como medio de prueba
Los mensajes de datos y los documentos firmados electrónicamente deberán ser
admitidos como prueba en los procesos judiciales y/o procedimientos administrativos.
Esto incluye la posibilidad de que a voluntad de las partes puede haberse utilizado un
servicio de intermediación electrónica.
El Juez podrá solicitar a la AAC el nombramiento de un perito especializado en firmas
electrónicas.
8
Artículo 1352.- Perfección de contratos
Los contratos se perfeccionan por el consentimiento de las partes, excepto aquellos que,
además, deben observar la forma señalada por la ley bajo sanción de nulidad.
9
Artículo 1411.- Forma como requisito
Se presume que la forma que las partes convienen adoptar anticipadamente y por
escrito es requisito indispensable para la validez del acto, bajo sanción de nulidad.
-8-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
El ordenamiento civil peruano, específicamente el Artículo 137410
del Código Civil ha legislado referente al Sistema de Conocimiento y
Contratación entre ausentes estableciéndose que en la recepción de
la declaración contractual (oferta, revocación y aceptación y
cualquier otra declaración contractual) a través de medios
electrónicos se considera conocida cuando el remitente reciba el
acuse de recibo.
En cuanto al Acto Administrativo, éste tendrá eficacia jurídica a
partir de la notificación legalmente realizada, es por ello que se
debe tener en consideración el Artículo 2011 de la Ley del
Procedimiento Administrativo General. Estos procedimientos
administrativos deben regirse conforme a Ley.
Es necesario garantizar la auditabilidad del sistema, esto se hace
factible mediante la incorporación de la bitácora digital, asimismo el
servicio de generación de microformas12.
10
“Artículo 1374.- Conocimiento y contratación entre ausentes
La oferta, su revocación, la aceptación y cualquier otra declaración contractual dirigida a
determinada persona se consideran conocidas en el momento en que llegan a la
dirección del destinatario, a no ser que éste pruebe haberse encontrado, sin su culpa, en
la imposibilidad de conocerla.
Si se realiza a través de medios electrónicos, ópticos u otro análogo, se presumirá la
recepción de la declaración contractual, cuando el remitente reciba el acuse de recibo”.
11
Artículo 20.- Modalidades de notificación
20.1 Las notificaciones serán efectuadas a través de las siguientes modalidades, según
este respectivo orden de prelación:
20.1.1 Notificación personal al administrado interesado o afectado por el acto, en su
domicilio
20.1.2 Mediante telegrama, correo certificado, telefax, correo electrónico; o cualquier
otro medio que permita comprobar fehacientemente su acuse de recibo y quien lo
recibe, siempre que el empleo de cualquiera de estos medios hubiese sido
solicitado expresamente por el administrado
20.1.3 Por publicación en el Diario Oficial y en uno de los diarios de mayor circulación en
el territorio nacional, salvo disposición distinta de la ley
20.2 La autoridad no podrá suplir alguna modalidad con otra, bajo sanción de nulidad de
la notificación. Podrá acudir complementariamente a aquéllas u otras, si así lo estimare
conveniente para mejorar las posibilidades de participación de los administrados
20.3 Tratamiento igual al previsto en este capítulo corresponde a los citatorios, los
emplazamientos, los requerimientos de documentos o de otros actos administrativos
análogos
12
Se establece en la certificación de digital a digital, cuyo contenido se incorporó con el Artículo 9º del
Decreto Supremo Nº 001-2000-JUS, sustituyendo el Artículo 25º del Decreto Supremo Nº 009-92-JUS:
Aprueban el Reglamento sobre la aplicación de normas que regulan el uso de tecnologías avanzadas
en materia de archivo de documentos e información a entidades públicas y privadas, siendo el texto el
siguiente:
“Artículo 25.- En las micrograbaciones tomadas directamente de medios cibernéticos, a
que se refiere el inciso c) del Artículo 7 de la ley se adoptarán las siguientes precauciones:
a) La micrograbación se realiza en microformas del tamaño establecido por los
requerimientos técnicos y de equipo.
b) Se aplican exclusivamente las formalidades indicadas en el presente Artículo 25. No son
de aplicación las que se indican en los Artículos 20, 21 y 22.
c) Mediante una forma fija sobrepuesta se grabará en cada imagen de la microforma la
firma del notario o fedatario juramentado protegida por signatura informática que incluye la
firma digital.
d) Además, en cada imagen de la microforma se mencionarán los números de las actas de
apertura y cierre correspondientes, con las iniciales que identifican al notario o fedatario
juramentado.
-9-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
1.4 Público al que va dirigido
Desarrolladores y proveedores de aplicaciones de software. El
documento asume que los lectores ya se encuentran familiarizados
con los fundamentos de Clave Pública y los fundamentos de la PKI.
1.5 Visión General
Este documento empieza con los antecedentes e información
contextual previa a la descripción de los requerimientos. Las
secciones 2 y 3 contienen estos antecedentes e información
contextual.
La sección 2 provee información sobre los antecedentes. El
propósito de la sección de antecedentes es establecer los términos
usados en el resto del documento.
La sección 3 establece los alcances de este documento. Esta sección
lista los documentos que moldean y complementan los
requerimientos encontrados en este documento. Esta sección
también identifica los tipos de aplicaciones a las cuales se aplican
los requerimientos.
La sección 4 contiene los requerimientos técnicos actuales que las
aplicaciones deben satisfacer.
La sección 5 establece los requerimientos de calificación. Estos
requerimientos identifican los métodos usados para determinar si la
aplicación satisface los requerimientos técnicos. Los requerimientos
de calificación incluyen interoperabilidad y requerimientos de
seguridad. Diversos apéndices complementan la información
contenida en el cuerpo de este documento.
e) Sólo se requiere un acta de apertura y un acta de cierre para cada grabación, no para
cada imagen de la microforma".
- 10 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
1.6
Rev: 05/04-02-2008
Aprobado:
Definiciones / Terminología
Acreditación: acto a través del cual la Autoridad Administrativa Competente,
previo cumplimiento de las exigencias establecidas en la Ley, en su Reglamento y
en las disposiciones dictadas por ella, faculta a las entidades solicitantes reguladas
en el Reglamento a prestar los servicios solicitados en el marco de la
Infraestructura Oficial de Firma Electrónica.
Agente automatizado: procesos y equipos programados para atender
requerimientos predefinidos y dar una respuesta automática sin intervención
humana, en dicha fase.
Aplicabilidad: se refiere al rango de aplicaciones en las que se puede utilizar un
certificado digital dentro de una comunidad. Este rango puede dividirse en tres
partes: (a) Aplicaciones libres, destinadas a miembros comunes de una
comunidad. (b) Aplicaciones restringidas a un grupo selecto dentro de la
comunidad. (c) Aplicaciones prohibidas para cualquier miembro de la comunidad.
Autenticación: proceso técnico que permite determinar la identidad de la
persona que firma electrónicamente, en función del mensaje firmado por éste y al
cual se le vincula. Este proceso no otorga certificación notarial ni fe pública.
Autoridad Administrativa Competente (AAC): organismo público responsable
de acreditar a las entidades de certificación y a las entidades de registro o
verificación, de reconocer los estándares tecnológicos aplicables en la
Infraestructura Oficial de Firma Electrónica, de supervisar dicha Infraestructura y
las otras funciones señaladas en el Reglamento o aquellas que requiera en el
transcurso de sus operaciones. Dicha responsabilidad recae en el Instituto
Nacional de Defensa de la Competencia y de la Protección de la Propiedad
Intelectual – INDECOPI.
Certificación cruzada: acto por el cual una certificadora acreditada reconoce la
validez de un certificado emitido por otra, sea nacional, extranjera o internacional,
previa autorización de la Autoridad Administrativa Competente y asume tal
certificado como si fuera de propia emisión, bajo su responsabilidad.
Certificado digital: documento electrónico generado y firmado digitalmente por
una entidad de certificación el cual vincula un par de claves con una persona
natural o jurídica confirmando su identidad.
Clave privada: es una de las claves de un sistema de criptografía asimétrica que
se emplea para generar una firma digital sobre un mensaje de datos y es
mantenida en reserva por el titular de la firma digital.
Clave pública: es la otra clave en un sistema de criptografía asimétrica que es
usada por el destinatario de un mensaje de datos para verificar la firma digital
puesta en dicho mensaje. La clave pública puede ser conocida por cualquier
persona.
- 11 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Código de verificación (hash o resumen): secuencia de bits de longitud fija
obtenida como resultado de procesar un mensaje de datos con un algoritmo, de
tal manera que: (1) El mensaje de datos produzca siempre el mismo código de
verificación cada vez que se le aplique dicho algoritmo. (2) Sea improbable, a
través de medios técnicos, que el mensaje de datos pueda ser derivado o
reconstruido a partir del código de verificación producido por el algoritmo. (3) Sea
improbable que, por medios técnicos, se pueda encontrar dos mensajes de datos
que produzcan el mismo código de verificación al usar el mismo algoritmo.
Criptografía asimétrica: rama de las matemáticas aplicadas que se ocupa de
transformar mensajes en formas aparentemente ininteligibles y devolverlas a su
forma original, las cuales se basan en el empleo de funciones algorítmicas para
generar dos “claves” diferentes pero matemáticamente relacionadas entre sí. Una
de esas claves se utiliza para crear una firma numérica o transformar datos en
una forma aparentemente ininteligible (clave privada) y la otra para verificar una
firma numérica o devolver el mensaje a su forma original (clave pública).
Las claves están matemáticamente relacionadas de tal modo que cualquier de
ellas implica la existencia de la otra, pero la posibilidad de acceder a la clave
privada a partir de la pública es técnicamente ínfima.
Declaración de prácticas de certificación (CPS): documento oficialmente
presentado por una entidad de certificación a la Autoridad Administrativa
Competente, mediante el cual define sus Prácticas de Certificación.
Declaración de prácticas de registro o verificación (RPS): documento
oficialmente presentado por una entidad de Registro o Verificación a la Autoridad
Administrativa Competente, mediante el cual define sus Prácticas de Registro o
Verificación.
Depósito de certificados: sistema de almacenamiento y recuperación de
certificados, así como de la información relativa a éstos, disponible por medios
telemáticos.
Destinatario: persona designada por el iniciador para recibir un mensaje de
datos o un documento electrónico siempre y cuando no actúe a título de
intermediario.
Documento: cualquier escrito público o privado, los impresos, fotocopias, facsímil
o fax, planos, cuadros, dibujos, fotografías, radiografías, cintas cinematográficas,
microformas tanto en la modalidad de microfilm como en la modalidad de
soportes informáticos y otras reproducciones de audio o video, la telemática en
general y demás objetos que recojan, contengan o representen algún hecho o una
actividad humana o su resultado. Los documentos pueden ser archivados a través
de medios electrónicos, ópticos o cualquier otro similar.
Entidad de certificación (EC): persona jurídica pública o privada que presta
indistintamente servicios de producción, emisión, gestión, cancelación u otros
servicios inherentes a la certificación digital. Asimismo, puede asumir las
funciones de registro o verificación.
Entidad de certificación extranjera: la que no se encuentra domiciliada en el
país, ni inscrita en los Registros Públicos del Perú, conforme a la legislación de la
materia.
- 12 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Entidad final: suscriptor o titular de un certificado digital.
Entidad de Registro o Verificación (ER): persona jurídica, con excepción de
los notarios públicos, encargada del levantamiento de datos, comprobación de
éstos respecto a un solicitante de un mecanismo de firma electrónica o
certificación digital, la aceptación y autorización de las solicitudes para la emisión
de un mecanismo de firma electrónica o certificados digitales, así como de la
aceptación y autorización de las solicitudes de cancelación de mecanismos de
firma electrónica o certificados digitales. Las personas encargadas de ejercer la
citada función serán supervisadas y reguladas por la normatividad vigente.
Estándares técnicos internacionales: requisitos de orden técnico y de uso
internacional que deben observarse en la emisión de firmas electrónicas y en las
prácticas de certificación.
Estándares técnicos nacionales: estándares técnicos aprobados mediante
Normas Técnicas Peruanas por la Comisión de Reglamentos Técnicos y
Comerciales – CRT de INDECOPI, en su calidad de Organismo Nacional de
Normalización.
Firmware13: es un bloque de instrucciones de programa para propósitos
específicos, grabado en una memoria tipo ROM, que establece la lógica de más
bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier
tipo. Funcionalmente, el firmware es la interfaz entre las órdenes externas que
recibe el dispositivo y su electrónica, ya que es el encargado de controlar a ésta
última para ejecutar correctamente dichas órdenes externas.
Hardware: es un neologismo proveniente del inglés, definido por la RAE como el
conjunto de los componentes que integran la parte material de una computadora;
sin embargo, es utilizado en una forma más amplia, generalmente para describir
componentes físicos de una tecnología.
Identificador de objeto OID: Es una cadena de números, formalmente definida
usando el estándar ASN.1 (ITU-T Rec. X.660 | ISO/IEC 9834 series), que
identifica de forma única a un objeto. En el caso de la certificación digital, los
OIDs se utilizan para identificar a los distintos objetos en los que ésta se enmarca
(por ejemplo, componentes de los Nombres Diferenciados, CPSs, etc.).
Referencia: http://www.oid-info.com/index.htm.
Infraestructura Oficial de Firma Electrónica (IOFE): sistema confiable,
acreditado, regulado y supervisado por la Autoridad Administrativa Competente,
provisto de instrumentos legales y técnicos que permiten generar firmas
electrónicas y proporcionar diversos niveles de seguridad respecto a: 1) la
integridad de los mensajes de datos y documentos electrónicos; 2) la identidad de
su autor, lo que es regulado conforme a la Ley. El sistema incluye la generación
de firmas electrónicas, en la que participan entidades de certificación y entidades
de registro o verificación acreditadas ante la Autoridad Administrativa
Competente, incluyendo a la Entidad de Certificación Nacional para el Estado
Peruano (ECERNEP), las Entidades de Certificación para el Estado Peruano (ECEP)
y las Entidades de Registro o Verificación para el Estado Peruano (EREP).
13
En el contexto de esta Guía de Acreditación, el firmware es el “sistema operativo” que proporciona
funcionalidades básicas como acceso seguro a la tarjeta inteligente, autenticación y cifrado.
- 13 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Integridad: característica que indica que un mensaje de datos o un documento
electrónico no ha sido alterado desde la transmisión por el iniciador hasta su
recepción por el destinatario.
Lista de Certificados Digitales Revocados (CRL o LCR): es aquella en la que
se deberán incorporar todos los certificados cancelados o revocados por la entidad
de certificación de acuerdo con lo establecido en el Reglamento de la Ley de
Firmas y Certificados Digitales.
Mecanismos de Firma Electrónica: un programa informático configurado o un
aparato informático configurado que sirve para aplicar los datos de creación de
firma. Dichos mecanismos varían según el nivel de seguridad que se les aplique.
Medios telemáticos: conjunto de bienes y elementos técnicos informáticos que
en unión con las telecomunicaciones permiten la generación, procesamiento,
transmisión, comunicación y archivo de datos e información.
Mensaje de datos: es la información generada, enviada, recibida, archivada o
comunicada por medios electrónicos, ópticos o similares, como pudieran ser, entre
otros, el intercambio electrónico de datos (EDI por sus siglas en inglés), el correo
electrónico, el telegrama, el télex o el telefax entre otros.
Middleware14: es un software de conectividad que ofrece un conjunto de
servicios que hacen posible el funcionamiento de múltiples procesos sobre
máquinas diferentes que deben interactuar. Proporciona las librerías que
implementan todas las funcionalidades que permiten la comunicación.
Neutralidad tecnológica: principio de no discriminación entre la información
consignada sobre papel y la información comunicada o archivada
electrónicamente, asimismo la no discriminación, preferencia o restricción de
ninguna de las diversas técnicas o tecnologías que pueden utilizarse para firmar,
generar, comunicar, almacenar o archivar electrónicamente información.
Niveles de seguridad: son los diversos niveles de garantía que ofrecen las
variedades de firmas electrónicas, cuyos beneficios y riesgos deben ser evaluados
por la persona, empresa o institución que piensa optar por una modalidad de
firma electrónica para enviar o recibir mensajes de datos o documentos
electrónicos.
Nombre Diferenciado X.501: es un sistema estándar diseñado para consignar
en el campo Sujeto de un certificado digital los datos identificativos del titular del
certificado, de manera que éstos se asocien de forma inequívoca con ese titular
dentro del conjunto de todos los certificados en vigor que ha emitido la EC. En
inglés se denomina “Distinguished Name”, DN X.501.
Par de claves: en un sistema de criptografía asimétrica, comprende una clave
privada y su correspondiente clave pública, ambas asociadas matemáticamente.
Política: Orientaciones o directrices que rigen la actuación de una persona o
entidad en un asunto o campo determinado
14
En el contexto de esta Guía de Acreditación, el middleware es el software que permite que una
aplicación que se ejecuta en una PC se comunique con una tarjeta inteligente y tenga acceso a sus
servicios; si fuera el caso, la comunicación se realiza a través de una lectora de tarjeta inteligente.
- 14 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Políticas de Certificación (CP): documento oficialmente presentado por una
entidad de certificación a la Autoridad Administrativa Competente, mediante el
cual establece, entre otras cosas, los tipos de certificados digitales que podrán ser
emitidos, cómo se deben emitir y gestionar los certificados, y los respectivos
derechos y responsabilidades de las Entidades de Certificación. Para el caso de
una EC Raíz, la CP incluye las directrices para la gestión del Sistema de
Certificación de las ECs vinculadas.
Práctica: Modo
operaciones.
o
método
que
particularmente
observa
alguien
en
sus
Prácticas de Certificación: prácticas utilizadas para aplicar las directrices de la
política establecida en la CP respectiva.
Prácticas específicas de Certificación: prácticas que completan todos los
aspectos específicos para un tipo de certificado que no están definidos en la CPS
respectiva.
Prácticas de Registro o Verificación: prácticas que establecen las actividades y
requerimientos de seguridad y privacidad correspondientes al Sistema de Registro
o Verificación de una ER.
Reconocimiento de servicios de certificación prestados en el extranjero:
proceso a través del cual la Autoridad Administrativa Competente acredita,
equipara y reconoce oficialmente a las entidades de certificación extranjeras.
Reglamento de la Ley de Firmas y Certificados Digitales: el Reglamento de
la Ley N° 27269 - Ley de Firmas y Certificados Digitales, modificada por la Ley N°
27310, aprobado por Decreto Supremo N° 004-2007-PCM del 12 de enero de
2007, y publicado en el Diario Oficial El Peruano con fecha 14 de enero de 2007.
Servicio de intermediación electrónica: servicio de valor añadido
complementario de la firma digital brindado dentro o fuera de la Infraestructura
Oficial de Firma Electrónica que permiten grabar, almacenar, conservar cualquier
información remitida por medios electrónicos que permiten certificar los datos de
envío y recepción, su fecha y hora, el no repudio en el origen y de recepción. El
servicio de intermediación electrónica dentro de la Infraestructura Oficial de Firma
Electrónica es brindado por persona jurídica acreditada ante la Autoridad
Administrativa Competente.
Servicio OCSP (Protocolo del estado en línea del certificado, por sus siglas en
inglés): permite utilizar un protocolo estándar para realizar consultas en línea al
servidor de la Autoridad de Certificación sobre el estado de un certificado.
Software: palabra de origen ánglico que hace referencia a todos los componentes
intangibles de una computadora, es decir, al conjunto de programas y
procedimientos necesarios para hacer posible la realización de una tarea
específica. Probablemente la definición más formal de software es la atribuida a la
IEEE, en su estándar 729: “la suma total de los programas de cómputo,
procedimientos, reglas, documentación y datos asociados que forman parte de las
operaciones de un sistema de cómputo”15.
15
IEEE Std, IEEE Software Engineering Standard: Glossary of Software Engineering Terminology.
IEEE Computer Society Press, 1993
- 15 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Suscriptor o titular de la firma digital: persona natural responsable de la
generación y uso de la clave privada, a quien se le vincula de manera exclusiva
con un mensaje de datos firmado digitalmente utilizando su clave privada. En el
caso que el titular del certificado sea una persona natural, sobre la misma recaerá
la responsabilidad de suscriptor. En el caso que una persona jurídica sea el titular
de un certificado, la responsabilidad de suscriptor recaerá sobre el representante
legal designado por esta entidad. Si el certificado está designado para ser usado
por un agente automatizado, la titularidad del certificado y de las firmas digitales
generadas a partir de dicho certificado corresponderán a la persona jurídica, la
cual deberá ser dueña del agente automatizado. La atribución de responsabilidad
de suscriptor, para tales efectos, corresponde al representante legal, que en
nombre de la persona jurídica solicita el certificado digital.
Tercero que confía o tercer usuario: se refiere a las personas naturales,
equipos, servicios o cualquier otro ente que actúa basado en la confianza sobre la
validez de un certificado y/o verifica alguna firma digital en la que se utilizó dicho
certificado.
Titular de certificado digital: persona natural o jurídica a quien se le atribuye
de manera exclusiva un certificado digital.
TSL (Lista de Estado de Servicio de Confianza, por sus siglas en inglés): lista de
confianza que incluye a los PSCs acreditados, autorizados a operar en el marco de
la IOFE. El propósito de la TSL es proveer de modo ordenado información del
estado de los proveedores de servicios, teniendo un rol preponderante en los
servicios considerados confiables (acreditados) y los proveedores supervisados
por la Autoridad Administrativa Competente.
Usabilidad16: es un término proveniente del inglés "usability", usado para
denotar la forma en la que una persona puede emplear una herramienta particular
de manera efectiva, eficiente y satisfactoria, en función de lograr una meta
específica. A esta idea van asociadas la facilidad de aprendizaje (en la medida en
que éste sea lo más amplio y profundo posible), la tasa de errores del sistema y la
capacidad del sistema para ser recordado (que no se olviden las funcionalidades ni
sus procedimientos).
16
Respecto a los temas de PKI, además del factor seguridad, la usabilidad también es importante para
lograr que los usuarios aprendan su uso con facilidad. Debe evitarse, por ejemplo, que una persona
entregue su tarjeta inteligente a otra por no entender, debido a su complejidad, el modo de usarla,
quebrantando así la seguridad del sistema.
- 16 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
1.7
RFC
RPS
SHA
SVA
TSL
VAPS
Aprobado:
Acrónimos
AAC
CC
CEN
CP
CPS
CRL o LCR
CRT
CWA
EC
ECEP
ECERNEP
ER
EREP
ETSI
FBCA
FIPS
IEC
IETF
IOFE
ISO
NTP
OCSP
OID
PKI
PSC
Rev: 05/04-02-2008
Autoridad Administrativa Competente (CRT del INDECOPI)
Common Criteria
Comité Europeo de Normalización
Políticas de Certificación
Declaración de Prácticas de Certificación de una EC
Certificate Revocation List (Lista de Certificados Revocados)
Comisión de Reglamentos Técnicos y Comerciales
CEN Workshop Agreements
Entidad de Certificación
Entidad de Certificación para el Estado Peruano
Entidad de Certificación Nacional para el Estado Peruano
Entidad de Registro o Verificación
Entidad de Registro para el Estado Peruano
European Telecommunications Standards Institute
Federal Bridge Certification Authority
Federal Information Processing Standards
International Electrotechnical Commission
Internet Engineering Task Force
Infraestructura Oficial de Firma Electrónica
International Organization for Standardization
Norma Técnica Peruana
Online Certificate Status Protocol
(Protocolo del estado en línea del certificado)
Identificador de Objeto
Public Key Infrastructure (Infraestructura de Clave Pública)
Prestador de Servicios de Certificación Digital
Prestador de Servicios de Criptográficos
Request for Comment
Declaración de Prácticas de Registro o Verificación de una ER
Secure Hash Algorithm
Prestador de Servicios de Valor Añadido
(por ejemplo TimeStamping)
Lista de Estado de Servicio de Confianza
Declaración de Prácticas de Valor Añadido
- 17 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
1.8
Rev: 05/04-02-2008
Aprobado:
Arquitectura Jerárquica de Certificación del Estado
Peruano y Mecanismo de Interoperabilidad
El Reglamento de la Ley N° 27269 - Ley de Firmas y Certificados
Digitales (modificada por la Ley N° 27310), aprobado por Decreto
Supremo N° 004-2007-PCM, designa al RENIEC como ECERNEP17,
ECEP y EREP18.
TSL
El mecanismo de interoperabilidad utilizado con el propósito de
proveer, de modo ordenado, la información del estado de los
Proveedores de Servicios de Certificación (PSCs) acreditados y
supervisados por INDECOPI –y por tanto autorizados a operar en el
marco de la IOFE– es la TSL, Lista de Estado de Servicio de
Confianza.
La TSL consiste en un lista “blanca” que contiene la relación de los
PSCs acreditados y es elaborada siguiendo el estándar ETSI TS102
231. Dicha lista es firmada digitalmente por INDECOPI a efectos de
asegurar su integridad y estará disponible para que las aplicaciones
de software puedan procesarla.
17
De acuerdo con el inciso a) del artículo 33º del Reglamento, la ECERNEP es la Entidad de
Certificación Nacional para el Estado Peruano, la cual será la encargada de emitir los certificados raíz
para las Entidades de Certificación para el Estado Peruano (ECEP), que así lo soliciten. Las EREPs
son aquellas Entidades de Registro o Verifcación cuyas funciones están vinculadas a una o más
ECEPs.
18
Artículo 34º.- Designación de las entidades responsables
Se designa al Registro Nacional de Identificación y Estado Civil - RENIEC como ECERNEP, ECEP y
EREP. Los servicios a ser prestados en el cumplimiento de los roles señalados estarán a disposición de
todas las Entidades Públicas del Estado Peruano y de todas las personas naturales y personas
jurídicas que mantengan vínculos con el mismo, no excluyendo ninguna representación del Estado
Peruano en el territorio nacional o en el extranjero.
Las entidades a que se refiere el artículo 33º del Reglamento serán acreditadas y reconocidas por la
AAC.
- 18 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
2.0 ANTECEDENTES
El propósito de esta sección es establecer la terminología a ser
usada en la descripción de los requerimientos de aplicación.
La criptografía simétrica se caracteriza porque ambas partes de
una comunicación requieren compartir la misma clave, tanto para
cifrar como para descifrar los datos de dicha comunicación. En este
sentido, para garantizar el secreto de sus comunicaciones es
necesario lo siguiente:
•
•
Un método fiable y seguro para distribuir la clave entre las
partes.
Que las partes mantengan la clave en secreto y que no la
hagan pública a terceros sin la aprobación y conocimientos de
la contraparte.
A diferencia de la criptografía simétrica, la criptografía asimétrica
utiliza distintas claves para el cifrado y descifrado19 de datos dentro
de una comunicación. Desde su generación, el par de claves tiene
una relación particular: los datos que son cifrados con una de las
claves sólo pueden ser descifrados con la otra clave, a fin de
acceder a los datos originales (texto en claro).
La criptografía de Clave Pública usa claves asimétricas en lugar de
las claves simétricas tradicionales. El propietario del par de claves
designa a una clave como clave privada y la otra como clave
pública. Es su deber mantener la clave privada en secreto y hacer
pública la otra clave, la cual puede ser publicada en repositorios
accesibles a terceros.
Las claves asimétricas pueden ser usadas para firmar o cifrar
información.
Durante el proceso de firma, el propietario utiliza su clave privada
para cifrar un resumen o hash20 del documento. El resumen
cifrado viene a ser la firma digital del documento, la cual es
adjuntada al documento original dando como resultado el
documento firmado.
19
Cuando se discute la criptografía asimétrica, el cifrado se refiere a la operación efectuada en datos
limpios (texto en claro) o no cifrados, para producir información cifrada, mientras que el descifrado se
refiere a la operación de transformar información cifrada a su forma original.
20
Los algoritmos hash y los algoritmos simétricos son usados para reducir la sobrecarga computacional
de la clave pública para procesos de firma y cifrado, respectivamente. Los algoritmos hash son
funciones criptográficas que convierten un mensaje de longitud variable en un mensaje resumen
(digest) o hash de longitud fija.
- 19 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Para verificar la autenticidad de la firma y la integridad del
documento firmado, el receptor realiza el proceso de verificación
siguiente:
a. Separa la firma digital del documento original.
b. Descifra la firma digital, utilizando la clave pública
perteneciente del remitente.
c. Obtiene un resumen o hash del documento original recibido
como parte del documento firmado.
d. Compara el resumen obtenido de descifrar la firma digital (b)
con el resumen obtenido del documento original (c). Si los
valores son iguales, el receptor puede tener la certeza de que
el documento firmado no ha sido alterado. Puesto que cada
clave pública puede descifrar solamente datos cifrados con la
correspondiente clave privada, el receptor tiene la seguridad
de la identidad del remitente de dicho documento firmado. Si
los valores no son iguales, esto implica que el mensaje fue
alterado, o que la clave pública usada no es el par de la clave
privada usada para firmar el documento.
Durante el proceso de cifrado, el remitente cifra los datos utilizando
la clave pública del receptor. Puesto que sólo el propietario posee la
clave privada correspondiente, sólo él puede descifrar la
información cifrada y acceder a los datos originales (texto en claro).
Para reducir las densas operaciones relativas al cifrado asimétrico,
el remitente de un mensaje puede realizar lo siguiente:
• Generar una clave simétrica, la clave de sesión (session
key).
• Cifrar el documento usando la clave de sesión.
• Cifrar la clave de sesión usando la clave pública del
destinatario.
• Transmitir el documento cifrado junto con la clave de sesión
cifrada.
La combinación del contenido cifrado y una clave de sesión cifrada
para un determinado destinatario, se denomina sobre digital
(digital envelope). El documento puede ser enviado a múltiples
destinatarios cifrando la clave de sesión y usando la clave pública
de cada destinatario e incluyendo las claves de sesión cifradas en el
sobre.
Las secciones previas han descrito las funciones primarias de la
criptografía de Clave Pública: cifrado y firma digital. Estas dos
funciones básicas soportan cuatro servicios distintos de seguridad:
- 20 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Autenticación: La autenticación es el proceso de verificación
y aseguramiento de la identidad de una persona natural o
jurídica.
Confidencialidad: La confidencialidad de los datos es la
protección de la información frente a una divulgación no
autorizada.
Integridad: La integridad de los datos es la protección de la
información frente a una modificación no autorizada y no
detectada.
No repudio: El no repudio asocia a una persona natural o
jurídica con los datos, de tal manera que la entidad no puede
negar su asociación con ellos ni reclamar eventuales
modificaciones de los mismos (falsificación).
La firma digital garantiza la autenticación, integridad y no repudio
de un documento firmado. El cifrado permite la confidencialidad de
los documentos cifrados. Los servicios basados en las firmas
digitales asumen que el propietario de la clave privada controla la
misma y asegura su secreto; es decir, sólo dicho propietario de la
clave privada puede emplearla. La verificación de un documento
firmado con una clave pública asegura que su propietario firmó el
documento. La Tabla 1 resume las operaciones de clave pública que
proveen los servicios.
Tabla 1. Métodos de clave pública usados para
proporcionar servicios de seguridad.
Servicio de Seguridad
Autenticación
Métodos de Clave
Pública
Firma
Confidencialidad
Cifrado
Integridad
Firma
No repudio
Firma
El proceso de verificación de una firma directamente soporta los
servicios de integridad porque puede detectar (pero no prevenir ni
corregir) la modificación no autorizada realizada con posterioridad a
la firma.
- 21 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
La asociación de la clave privada con su propietario evita que éste
deniegue la autoría del documento firmado. Así, las firmas soportan
los servicios técnicos de no repudio. Técnicamente, las firmas no
pueden ser negadas. Una firma que se verifica con una clave
pública particular tuvo que ser firmada con la clave privada
asociada. La verificación puede ser realizada por cualquier otra
persona (terceros que confían) en cualquier momento21. Sin
embargo, el no repudio técnico por sí mismo puede no ser suficiente
para un no repudio legal, en el cual una persona pueda ser
reconocida legalmente como autor de la firma digital.
Existen circunstancias bajo las cuales un documento firmado
digitalmente puede ser repudiado:
Cuando una persona, diferente al suscriptor, ha tenido acceso
a la clave privada a pesar de que este último haya sido
precavido al proteger la clave.
Cuando un suscriptor es estafado, forzado o coaccionado en el
momento de efectuar la firma.
Para garantizar la confiable asignación del par de claves a una
persona natural o jurídica y evitar la usurpación de identidad o
estafa es necesaria la presencia de una tercera parte confiable
(Trusted Third Party, TTP), que en una PKI es la Entidad de
Certificación (EC), la cual relaciona al par de claves con un
certificado digital (certificado de clave pública o certificado),
el cual a su vez es un documento firmado digitalmente por la EC
que lo emite, que incluye el nombre del suscriptor y/o el titular
del certificado digital. En el caso de una persona natural, el
suscriptor es el responsable de la posesión del par de claves, titular
del certificado digital y titular de la firma digital. En el caso de
una persona jurídica, el suscriptor es una persona natural
responsable de la posesión del par de claves y titular de la firma
digital, el cual es asignado por la persona jurídica, siendo ésta el
titular del certificado digital. El certificado incluye información
adicional relativa a la PKI, y los usos que la EC pretende para el
certificado.
Las EC utilizan los servicios de una Entidad de Registro o
Verificación (ER), para la verificación de la identidad de los
solicitantes de los certificados digitales.
21
Puede haber un límite para el período durante el cual la verificación puede darse, como se discutirá
posteriormente.
- 22 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Cuando un certificado digital es emitido, el par de claves es
generado primero, luego la clave pública es enviada a la EC. A
continuación, la EC genera el certificado digital (y podría publicarlo
en su Repositorio), lo firma digitalmente y lo envía para el
correspondiente proceso de verificación. El Repositorio permite que
los usuarios puedan obtener copias de los certificados que
pertenecen a un individuo y, por consiguiente, puedan obtener la
clave pública del suscriptor a partir del certificado.
Un usuario que obtiene una clave pública de un certificado y
depende de la asociación entre el nombre del propietario y la clave
pública y de alguna otra información contenida en el certificado, es
un tercero que confía (relying party) o tercer usuario. La Tabla 2
muestra cuál es el rol del suscriptor y del tercero que confía (tercer
usuario) cuando se usan los métodos de clave pública.
Tabla 2. Operaciones del suscriptor y del tercero que confía.
Función
Tercero que Confía
Suscriptor
(tercer usuario)
Cifrado
Descifra los datos recibidos
usando la clave privada.
Cifra los datos usando la clave
pública del suscriptor receptor.
Firma
Digital
Cifra (firma) datos usando la
clave privada.
Descifra los datos usando la
clave pública del suscriptor
firmante
para
verificar
la
integridad del documento y la
autenticidad de la firma digital.
A fin de garantizar una correcta verificación de la identidad de la
persona natural o jurídica que solicita un certificado digital, como
parte de la infraestructura PKI, existen las Entidades de Registro o
Verificación (ER), las cuales garantizan que el propietario del par de
claves sea correctamente identificado, y trabajan conjuntamente
con las EC.
La EC se encarga de emitir y administrar el ciclo de vida de los
certificados digitales emitidos y, además, proporciona información
sobre el estado actual de un certificado a través de una Lista de
Certificados
Digitales
Revocados
–LCR–
(Certificate
Revocation List, CRL) o de una verificación en línea del estado del
certificado (Online Certificate Status Protocol, OCSP). Como
resultado de ciertas circunstancias adversas, algunos certificados
pueden dejar de ser confiables. La EC revocará un certificado
cuando sea informada de circunstancias que ya no garanticen la
confianza del mismo.
- 23 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
El certificado revocado será incluido en las próximas CRLs que la EC
emita. Luego que un Respondedor OCSP (OCSP Responder,
OCSPR) recibe una CRL u otra notificación de la EC con relación al
certificado revocado, éste responderá con una indicación de
revocación para subsecuentes consultas relativas a dicho
certificado.
La CRL es el más antiguo de los dos métodos de verificación de
estado. La CRL tiene un encabezado que proporciona información
general que incluye:
• El nombre del emisor de la CRL que usualmente es el mismo
que el de la EC que emitió los certificados revocados.
• La fecha22 en que fue producida la CRL.
• La próxima fecha de actualización. La EC se compromete a
producir una nueva CRL a más tardar en la fecha que figura
en la CRL. La EC puede producir una nueva CRL antes de la
fecha indicada. La CRL expira en la fecha de la próxima
actualización.
La CRL lista los certificados revocados de manera individual
mediante su número de serie junto con la fecha en que cada
certificado fue revocado y, además, puede incluir un código con el
que se indica la razón de dicha revocación.
Los certificados expiran al final de su período de validez y, si fuera
el caso, son removidos de las CRLs emitidas después de su fecha de
expiración. La EC firma digitalmente la CRL. Con la firma de la EC,
las CRLs pueden ser transmitidas a través de enlaces de
comunicación inseguros puesto que cualquier cambio subsiguiente
será detectado a través del proceso de verificación de la firma.
La EC periódicamente emite las CRLs. La EC puede emitir las CRLs a
intervalos dados de tiempo o en respuesta a un evento como la
revocación de un certificado debido a la sospecha que la clave
privada ha sido comprometida. La EC distribuye la CRL en un lugar
donde los terceros que confían (terceros usuarios) pueden obtener
la CRL más actualizada. Dicho lugar es conocido como Punto de
Distribución de CRL (CRL Distribution Point, CDP) y
usualmente especificado en términos de un Indicador Uniforme de
Recursos (Uniform Resource Indicador, URI).
22
En este documento el término fecha denota un valor que tiene dos componentes: un día calendario y
un tiempo dentro del día.
- 24 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
El OCSP es el otro método para verificar la validez de un certificado.
El OCSP es el servicio que puede ser proporcionado por la EC o
algún otro TTP. Un tercero que confía (tercer usuario) envía una
solicitud al servicio OCSP con un certificado, éste responde con una
respuesta firmada digitalmente que incluye fecha y hora, la
identificación del certificado, y el estado del certificado sobre cuya
validez el tercero que confía (tercer usuario) realizó la consulta. Las
posibles respuestas incluyen "desconocimiento" (“unknown”) la cual
puede ser la respuesta a una consulta sobre un certificado expirado.
Los terceros que confían (terceros usuarios) deben efectuar la
consulta del estado del certificado sin importar si se usa CRLs u
OCSPRs para verificar el estado del mismo. El propósito de una
revisión del estado del certificado es asegurar que el certificado
continúa siendo confiable. Los terceros que confían (terceros
usuarios) son responsables de verificar el estado del certificado,
dado que se debe evitar perjuicios generados como resultado de
utilizar un certificado revocado.
Las ECs pueden existir en jerarquías. Una EC puede delegar
responsabilidades a otra EC. Una EC delega responsabilidad a otra a
través de la emisión de un certificado para una EC intermedia. El
contenido de este certificado puede establecer las restricciones en
las facultades delegadas a las ECs intermedias para emitir los
subsiguientes certificados. La EC que se encuentra en la cima de la
jerarquía es la EC Raíz (Root CA). El certificado de una EC Raíz ha
sido firmado por sí mismo (self-signed). Las ECs intermedias
emiten certificados a individuos que no pueden actuar como ECs y
que no pueden emitir certificados. Un individuo que no puede emitir
certificados es conocido como una entidad final23 (end-entity).
A fin de tener certeza de la confiabilidad de un certificado digital y
de la entidad emisora, el tercero que confía (tercer usuario) debe
verificar uno o más puntos de confianza (trust points), que son
las claves públicas (o certificados que las contienen) de los
Prestadores de Servicios de Certificación Digital (EC, ER, SVA) que
son designados como confiables y fidedignos por la IOFE. Los
terceros que confían deben obtener las claves públicas (o los
certificados) a través de algún método de distribución masiva
confiable.
23
Suscriptor o titular de un certificado digital.
- 25 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Los puntos de confianza son usualmente la lista de Proveedores de
Servicios de Certificación (EC, ER, SVA) de confianza –TSL- y los
Certificados Raíz24 contenidos en aquélla. La confianza es
transmisible, si la IOFE declara como confiable a una EC raíz, se
entiende que son también confiables las EC intermedias a las cuales
la EC raíz ha delegado sus responsabilidades.
El tercero que confía (tercer usuario) puede fiarse del certificado de
una entidad final si es que existe una secuencia de certificados que
conectan el certificado de la entidad final a alguno de los puntos de
confianza verificables por el tercero que confía. La secuencia es
conocida como ruta o cadena de certificación. La construcción de
la ruta es conocida como desarrollo de la ruta (path
development), y la verificación de que la ruta proporciona una
cadena de confianza es conocida como procesamiento de la ruta
(path processing). El desarrollo y procesamiento de la ruta
pueden sucederse secuencialmente o en paralelo. La ruta empieza
con un certificado digital de una EC Raíz (el cual debe estar incluido
en la lista TSL) prosigue con los certificados de las EC intermedias y
finaliza con el certificado de la entidad final25.
El proceso de verificación de la ruta incluye:
• Verificación de las firmas de los certificados.
• Verificación de la cadena de certificados. Si el titular (subject)
en un certificado es el emisor (issuer) del siguiente.
• Aseguramiento que el uso específico del certificado es
consistente con el uso propuesto para dicho certificado como
se indica en el contenido del mismo.
• Aseguramiento que ninguno de los certificados incluidos en la
ruta han sido revocados, ni han expirado.
• Aseguramiento que la EC emisora se encuentre contenida en
la lista TSL; es decir, que sea una Entidad de Certificación
acreditada por el INDECOPI, en su calidad de AAC.
Podría haber un retraso entre el tiempo en que un certificado es
revocado y el tiempo en que, o bien la CRL es actualizada o bien el
OCSPR es informado de dicha revocación. Como resultado, existe la
posibilidad de que un tercero que confía (tercer usuario) pueda
confiar en un certificado después de que ha sido revocado pero
antes de que ocurriera la actualización de la CRL o la notificación al
OCSPR. Algunos terceros que confían podrían ser afectados en este
tipo de situaciones. Dos enfoques para evitar esto son:
24
En determinadas circunstancias un tercero que confía puede decidir confiar en una EC intermedia o
incluso en una entidad final.
25
La elección de la orientación de la cadena es discrecional. La cadena podría ser ordenada desde la
entidad final hasta un punto de confianza. El orden no es importante, siempre y cuando la ruta de
certificación resultante sea la misma.
- 26 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
•
Mantener suspendido durante un lapso especificado de tiempo
el procedimiento de verificación de la CRL. Según el
documento del APEC26, el tiempo máximo que debe existir
entre la notificación de la solicitud de revocación de certificado
y emitir una CRL que incluya dicho certificado como revocado
es de 24 horas. Este acercamiento puede prevenir el que se
acepte una firma inválida pero involucra retrasos en el
procesamiento, lo que no es práctico en situaciones como la
autenticación cercana al acceso en tiempo real de los sistemas
o medios.
•
Revisar las CRLs con posterioridad al tiempo máximo
establecido –24 horas– para determinar si un certificado
recientemente agregado a la CRL fue procesado luego de su
revocación e identificar dichos certificados para un
procesamiento especial. Esta aproximación puede contribuir a
prevenir el que se acepten firmas inválidas pero con un
tiempo posterior de 24 horas, facilita el descubrimiento de
una firma con un certificado revocado, pero después de
sucedido el hecho.
Los certificados tienen un tiempo de vida27. El período en que los
certificados son válidos es determinado por el contenido en su
campo de validez. Los certificados para usuarios generalmente
tienen uno a tres años de tiempo de vida. Los certificados de la EC
tienen un tiempo de vida más largo. El tiempo de vida de un
certificado de EC tiene que abarcar el tiempo de vida de todos los
certificados que ésta emite. Esta anidación de tiempos de vida de
certificados es necesaria para el procesamiento de la ruta.
La vida limitada de los certificados puede impactar sobre algunas
aplicaciones. Los certificados que pertenecen a ECs y a otras
entidades expiran y tienen que ser reemplazados. Las ECs pueden
tener múltiples certificados. La necesidad de anidar los tiempos de
vida de certificados significa que las ECs no pueden emitir
certificados cuando el período de validez de un nuevo certificado
excede el período de validez de su propio certificado. Por ejemplo,
si una EC tiene un certificado con tiempo de vida de cinco años y
otorga certificados para usuarios con tiempos de vida máximos de
tres años, la EC sólo puede usar su certificado para crear nuevos
certificados de usuarios durante sus dos primeros años, y así
periódicamente. La EC deberá obtener un nuevo certificado cuando
ésta ya no pueda emitir nuevos certificados relativos a su antiguo
certificado.
26
Guidelines for the Certificate Policy and Certificate Practices Framework for issuing certificates
capable of being used in Cross Jurisdiction e-Commerce.
27
Las razones para limitar el tiempo de vida incluyen el control del tamaño de la CRL y el riesgo de que
la clave privada pueda ser descubierta.
- 27 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Las aplicaciones que procesan los certificados emitidos por una EC
podrían tener que encontrar un certificado particular entre varios
emitidos a una EC. Por ejemplo, considere el caso de dos usuarios
que han recibido, por parte de la EC del ejemplo antes mencionado,
certificados por un periodo de validez de tres años. Si los usuarios
tramitaron sus certificados con una diferencia de más de dos años,
la aplicación de software utilizará un certificado de EC diferente para
verificar sus firmas digitales.
Tanto las entidades como los individuos que no son ECs también
pueden tener múltiples certificados. Los individuos deben tener
diferentes certificados para propósitos distintos: un certificado para
firma y/o autenticación, otro para cifrado, e incluso cada uno de
estos podría ser para fines aún más específicos. Las aplicaciones
deberán estar capacitadas para seleccionar un certificado apropiado
desde los múltiples certificados existentes. Esta situación puede
darse en aplicaciones que deben guardar información durante un
largo periodo y deberían haber almacenado los resultados de la
verificación de las firmas, el estado de la EC en la TSL, así como
toda la cadena confiable de certificados que en su momento los
validaron, pudiendo ser en el presente estos certificados ya
expirados desde hace algún tiempo28.
Cuando el periodo de vida de certificado está pronto a expirar en un
tiempo menor a un año, los suscriptores pueden solicitar el proceso
de re-emisión. Este proceso implica la emisión de un certificado
con un nuevo par de claves manteniendo los mismos datos
correspondientes al certificado anterior, a excepción del número de
serie, el período de validez y la clave pública.
Los suscriptores no deben usar la clave privada asociada con un
certificado expirado para realizar firmas digitales y deben destruir la
clave privada incluyendo cualquier copia. Aunque los terceros que
confían en realidad no deben usar certificados expirados para
verificar las firmas, pues el software de firma debe de almacenar
(firmado digitalmente) los resultados del proceso de validación
previo a la realización de la firma, durante la primera validación
podrían necesitar los certificados para confirmar de manera
independiente la verosimilitud (por ejemplo, reconfirmar) de las
firmas verificadas previamente.
28
La presunción aquí es que la información cifrada no tendrá que ser retenida por largos períodos o
será cifrada nuevamente con una nueva clave debido al incremento de riesgos de que la clave del
cifrado original sea descubierta.
- 28 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Los suscriptores deben mantener el acceso a las claves privadas
como requisito para descifrar cualquier información retenida en
formato cifrado. Por ejemplo, el suscriptor podría necesitar la clave
privada para descifrar y ver cualquier documento recibido
previamente y aún mantenido en formato cifrado29. La Tabla 3
resume el manejo de claves y certificados cuando los certificados
expiran.
Tabla 3. Disposición de clave y certificado frente a la expiración del
certificado.
Aplicación
Firma Digital
(Autenticación,
integridad, no
repudio)
Clave Privada
Clave Pública y Certificado
Destrucción, prevenir cualquier
uso posterior
El cese en el uso de cualquier
nueva firma. Retener para
aplicaciones de no repudio
tanto
tiempo
como
se
almacenen datos firmados,
previamente
verificados,
y
permanezcan
sujetos
a
verificación.
Se debe considerar la provisión
de medidas para probar la
recepción
previa
a
la
expiración del certificado (o
revocación)
y
no
modificaciones posteriores.
Cifrado
(Confidencialidad)
Retener copia personal y de
recuperación de datos de la
clave, mientras se mantengan
guardados los datos cifrados.
Destrucción; cese del uso.
Considerar el volver a cifrar
con otra clave si el periodo de
almacenamiento
excede
el
tiempo de vida de la clave.
Dentro de la IOFE, las ECs acreditadas pueden contar con políticas
de recuperación de claves de descifrado (no está permitida la
recuperación de claves para los certificados de firma digital ni
autenticación) para asegurar que la información cifrada pueda
recuperarse en casos legalmente establecidos y para la continuidad
operacional. Los certificados utilizados para el cifrado no deben ser
utilizados para los procesos de firma y/o autenticación, y viceversa.
29
La clave privada también puede ser necesitada para ver mensajes que el suscriptor envió en formato
cifrado, porque los clientes del correo a menudo mantienen los mensajes como texto cifrado en lugar de
texto en claro por razones de seguridad. Efectivamente, los clientes incluyen al suscriptor como un
destinatario para mensajes cifrados que el suscriptor envía.
- 29 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Las aplicaciones de software en el curso de provisión de los
servicios de seguridad a sus usuarios se sostienen en las
necesidades tanto del suscriptor como del tercero que confía (tercer
usuario). Las aplicaciones deben realizar las funciones descritas
anteriormente como apropiadas en el dominio de la aplicación
empleada.
- 30 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
3.0 DOCUMENTOS APLICABLES Y ALCANCES
Esta sección establece el contexto de los requisitos técnicos para
habilitar aplicaciones dentro del marco de la IOFE. Las aplicaciones
deben cumplir y deben ser consistentes con la política global de la
IOFE para los niveles de aseguramiento de las aplicaciones y el uso
de la PKI. Las siguientes subsecciones identifican los documentos
que proporcionan la política y los requerimientos técnicos de las
aplicaciones y los tipos de aplicaciones que pueden usar la PKI de la
IOFE.
3.1 Documentos Aplicables
En esta subsección se referencian las normas y estándares que
proveen una política global y guía para el desarrollo de aplicaciones
en la IOFE. Los desarrolladores de aplicaciones deben cumplir tanto
con los requisitos de estas referencias, así como los señalados en el
presente documento. El acrónimo dentro de los corchetes -[ ]- que
aparece antes de que cada referencia se usará en el resto del
documento para referirse al correspondiente documento aplicable al
que se asocia:
[Ley 27269 y anexos]
Ley de Firmas y Certificados Digitales,
su
Reglamento
y
Disposiciones
Complementarias
[APEC]
Guidelines for the Certificate Policy and
Certificate Practices Framework for
issuing certificates capable of being
used
in
Cross
Jurisdiction
eCommerce.
[TSL ETSI TS102.231 v2.0] Electronic
Signatures
and
Infraestructures (ESI); Provision of
Harmonized Trust service Provider
Satus Information.
[ISO/IEC 15408]
International
Standard
15408)
for
Computer
Common Criteria
- 31 -
(ISO/IEC
Security:
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
[RFC 3628]
On Policy Requirements for
Stamping Authorities (TSAs)
[RFC 3161]
Internet
X.509
Public
Key
InfrastructureTime-Stamp
Protocol
(TSP).
[FIPS 46]
Instituto Nacional de Estándares y
Tecnología. Estándar de Cifrado de
Información Standard – DES. FIPS PUB
46 – 3, 25 de Octubre de 1999.
[FIPS140-2]
Instituto Nacional de Estándares y
Tecnología.
Requerimientos
de
Seguridad para Módulos de Cifrado.
FIPS PUB 140 – 2, Noviembre de
1999.
[FIPS180]
Instituto Nacional de Estándares y
Tecnología. Estándar de Seguirdad
Hash (SHS). FIPS PUB 180 – 1. 17 de
Abril, 1995.
[FIPS186]
Instituto Nacional de Estándares y
Tecnología. Estándar de Firma Digital
(DSS). FIPS 186 – 2. 27 de Enero del
2000.
[FIPS196]
Instituto Nacional de Estándares y
Tecnología. Autenticación de Entidad
usando Criptografía de Clave Pública.
FIPS 196. Febrero de 1997.
[RFC 2459]
Internet X.509 Perfil de CRL y
Certificado de Infraestructura de Clave
Pública. Enero de1999.
- 32 -
Time-
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
3.2 Niveles de Seguridad de PKI
El nivel de seguridad asociado con un certificado de clave pública es
una aserción por parte de una EC del grado de confianza que un
usuario puede tener razonablemente en el vínculo de laclave pública
de un suscriptor con el nombre y los atributos consignados en el
certificado, por lo que se definen múltiples niveles de seguridad.
Es de conocimiento general que no basta un único nivel de
seguridad para todas las aplicaciones de PKI. Algunas aplicaciones
que son menos críticas o que implican alguna transacción de bajo
valor monetario pueden resistir un riesgo mayor comparado con
otras aplicaciones que requieren de una mayor nivel de seguridad.
La PKI de la IOFE recoge estas tendencias y presenta los niveles de
seguridad Medio, Medio Alto y Alto, descritos en el siguiente cuadro.
Características
Nivel de Seguridad
Medio
Nivel de Seguridad
Medio Alto
Nivel de Seguridad
Alto
Aplicación en el
intercambio de
información
Trámites con el Estado en las
transacciones económicas de
monto bajo o medio y para el
intercambio de documentos de
riesgo bajo o medio.
• Intercambio de documentos y
transacciones monetarias de
alto riesgo.
• Trámites con el Estado en las
transacciones económicas de
alto monto y alto riesgo.
Para información crítica
clasificada o de seguridad
nacional.
Aplicación en
Firma Digital
Para información crítica y de
seguridad nacional en redes
cifradas.
Para información crítica no
clasificada o de seguridad
nacional en una red no cifrada.
Para información crítica
clasificada o de seguridad
nacional en una red no cifrada.
Aplicación en
control de acceso
Para el acceso a información
clasificada o información de
acceso especial en redes
protegidas.
Para el acceso a información
clasificada o información de
acceso especial en redes no
protegidas.
Protección (autenticación y
confidencialidad) para
información que cruza los
límites de la clasificación
cuando dicho límite es aún
permitido por las políticas de
seguridad del sistema.
Aplicación en el
campo financiero
Aplicaciones de valor financiero
medio o de comercio
electrónico, tales como las
planillas, contratos, compra de
vehículos, etc.
Aplicaciones de valor financiero
de riesgo y monto medio alto o
de comercio electrónico.
Aplicaciones de valor financiero
de riesgo y monto alto o de
comercio electrónico.
Dispositivos
criptográficos
Los dispositivos criptográficos
físicos –hardware y firmware
(sistema operativo)– que
almacenan las claves privadas
de la entidad final –usuarios–
deben de cumplir con la
certificación FIPS 140-2 Nivel
de Seguridad 1 (mínimo).
Los dispositivos criptográficos
físicos –hardware y firmware
(sistema operativo)– que
almacenan las claves privadas
de la entidad final –usuarios–
deben de cumplir con la
certificación FIPS 140-2 Nivel
de Seguridad 2 (mínimo).
Los dispositivos criptográficos
físicos –hardware y firmware
(sistema operativo)– que
almacenan las claves privadas
de la entidad final –usuarios–
deben de cumplir con la
certificación FIPS 140-2 Nivel
de Seguridad 3 (mínimo).
- 33 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Longitud de la
clave privada
Hasta el año 2009 se admitirá
que la longitud de clave
privada mínima sea de 1024
bits y el certificado debe ser
renovado como máximo
anualmente. Si la longitud de
la clave privada es de 2048
bits, el certificado debe ser
renovado como máximo cada
tres (3) años.
La longitud de clave privada
mínima debe ser de 2048 bits y
el certificado debe ser renovado
como máximo cada dos (2)
años.
La longitud de clave privada
mínima debe ser de 2048 bits y
el certificado debe ser renovado
como máximo anualmente.
Generación de la
clave privada
Los certificados a nivel de
entidad final –usuarios– deben
ser generados de manera
individual y separados para las
siguientes funciones: cifrado y
firma (no repudio) o
autenticación. Las funciones
de firma y autenticación son
compatibles y pueden ser
realizadas con un mismo
certificado.
Los certificados a nivel de
entidad final –usuarios– deben
ser generados de manera
individual y separados para las
siguientes funciones: cifrado y
firma (no repudio) o
autenticación. Las funciones
de firma y autenticación son
compatibles y pueden ser
realizadas con un mismo
certificado.
Los certificados a nivel de
entidad final –usuarios– deben
ser generados de manera
individual y separados para las
siguientes funciones: cifrado,
firma (no repudio) y
autenticación.
ER:
ER:
ER:
•
Verificación de la
identidad empleando
la base de datos del
RENIEC
•
Sin certificación; sólo
cuenta con la
aprobación de las
auditorías
correspondientes para
la acreditación o
implementación de
las normas
correspondientes
EC:
Certificaciones de
seguridad o
calidad del
Prestador de
Servicios de
Certificación
Digital – PSC
SVA:
•
SW:
30
•
Sin certificación; sólo
cuenta con la
aprobación de las
auditorías
correspondientes para
la acreditación o
implementación de
las normas
correspondientes
Sin certificación; sólo
cuenta con la
aprobación de las
auditorías
correspondientes para
la acreditación o
implementación de
las normas
correspondientes
•
Verificación de la
identidad empleando
el sistema de
identificación
biométrica AFIS del
RENIEC
•
•
ISO 27001
Cumplimiento del
estándar WebTrust for
Certification
Authorities y
obtención del sello de
Webtrust, a partir del
año 201130
EC:
ISO 9001:2000
Verificación de la
identidad empleando
el sistema de
identificación
biométrica AFIS del
RENIEC
•
•
ISO 27001
Cumplimiento del
estándar WebTrust for
Certification
Authorities y
obtención del sello de
Webtrust, a partir del
año 2011
EC:
SVA:
•
SW:
•
•
•
Certificación de
acuerdo al Decreto
Legislativo Nº 681,
ISO 9001:2000 o ISO
27001
SVA:
•
SW:
ISO 9001:2000, CMMI
nivel 2 (mínimo) u
otro equivalente que
el INDECOPI
determine
•
Certificación de
acuerdo al Decreto
Legislativo Nº 681,
ISO 9001:2000 o ISO
27001
ISO 9001:2000 o
CMMI nivel 3
(mínimo) u otro
equivalente que el
INDECOPI determine
Los detalles de este requisito serán publicados en la siguiente versión de la Guía de Acreditación.
- 34 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.0 REQUERIMIENTOS
Las organizaciones que desarrollan una aplicación de software para
su uso en el marco de la IOFE son responsables de asegurar que la
aplicación en su medio operacional satisfaga los requerimientos de
esta sección, al margen de si los servicios son provistos de manera
interna o externa.
Las aplicaciones de software deben cumplir todos los requerimientos
que se mencionan en el presente documento. Incluso mientras la
TSL de la AAC aún no se encuentre implementada, todos los
requerimientos que no dependan directamente de la misma deben
ser cumplidos sin excepción.
Las aplicaciones pueden proveer las funciones internas necesarias
(librerías, por ejemplo: os, dll, ocx, u otros) o asegurar que la
aplicación pueda operar en un medio en el cual existen otras
aplicaciones externas o servicios que proveen dichas funciones.
4.1 Requerimientos Generales
Los siguientes requerimientos generales se aplican de manera
global a la aplicación.
4.1.1 Automatización preferente de los Procedimientos
Existen métodos alternativos para satisfacer los requisitos descritos
a continuación. Algunos requisitos pueden ser satisfechos usando
características automatizadas o procedimientos manuales. Las
aplicaciones deben proveer características automatizadas, siempre
que ello sea posible. Cuando no sea factible, las aplicaciones
deberán incluir instrucciones apropiadas en los documentos
relacionados, tales como las guías de configuración y manuales del
administrador y del usuario (o equivalentes automatizados como los
archivos de ayuda).
4.1.2 Uso de Módulos Criptográficos Evaluados
Las aplicaciones deben emplear Módulos Criptográficos evaluados –
en adelante denominado módulos acreditados– bajo el Estándar
FIPS 140-2: Nivel 1 para los certificados de usuario final, Nivel 2
para los certificados de la ER, y Nivel 3 para los certificados de la
EC como mínimo. Debido a que las aplicaciones pueden emplear
varias funciones criptográficas, éstas pueden depender de múltiples
módulos. Por ejemplo, un token físico usado para operaciones de
clave pública y el software usados para el cifrado simétrico pueden
estar en módulos separados.
- 35 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.1.3 Seguridad del computador
Las aplicaciones deben mantener un ambiente computacional
seguro para la operación de la aplicación. Las aplicaciones deben
asegurar que se hayan implementado medidas de seguridad que
permitan:
•
•
•
•
•
Identificar y autenticar a los usuarios de la aplicación.
Controlar el acceso a los objetos criptográficos críticos de la
aplicación y funciones basadas en la identidad del usuario y
autorización de acceso. Los objetos criptográficos incluyen
claves, puntos de confianza y certificados. El acceso a las
claves privadas debe limitarse a personas autorizadas para
tales efectos.
Deben mantenerse archivos auditables respecto al uso de las
características criptográficas de la aplicación.
Proteger los objetos y las funciones criptográficas de la
aplicación frente a manipulaciones.
Asegurar la separación de información cifrada y no cifrada.
4.2 Requerimientos Específicos
Las funciones de la aplicación pueden ser agregadas en varias
familias relacionadas. Estas familias son:
•
•
•
•
Manejo de claves que incluye las funciones de generar y
almacenar el par de claves; así como almacenar y guardar los
puntos de confianza. La seguridad de las claves privadas y los
puntos de confianza es crítica.
Interfaz PKI que incluye funciones para el uso de los servicios
de la PKI.
Servicios de cifrado que incluyen las funciones para cifrar y
descifrar información usando tanto los algoritmos de cifrado
simétricos como asimétricos y para calcular el mensaje
resumen (hash o digest). Estos servicios también incluyen la
generación de claves simétricas y números aleatorios
(random).
Procesamiento de verificación necesarios antes y después de
realizar el proceso de firma, cifrado y autenticación, que
comprenda funciones para verificar la TSL, así como para
obtener cadenas de certificación que incluyan la verificación
de la validez de los certificados de la cadena.
Las siguientes subsecciones describen los requerimientos para cada
familia de funciones.
- 36 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.1 Manejo de Claves
Las aplicaciones deben realizar “todas o algunas” de las funciones
de manejo de claves según sea necesario. Las funciones de manejo
de las claves se refieren al mantenimiento y protección permanente
de los objetos criptográficos. Estas funciones incluyen:
•
•
•
•
•
Generación del par de claves asimétricas (pública y privada).
Almacenamiento del par de claves y del certificado
correspondiente. El servicio de almacenamiento de claves
debe asegurar que la clave privada no sea comprometida o se
pierda.
Almacenamiento y protección de los certificados que son
puntos de confianza.
Custodia o copia de las claves usadas para cifrado para
efectos de recuperación de la información.
Importar y exportar pares de claves y certificados
relacionados.
Las siguientes subsecciones desarrollan cada uno de estos puntos.
La generación y protección de las claves simétricas serán discutidas
en la Sección 4.2.3.
Las aplicaciones deben usar módulos criptográficos acreditados por
la IOFE. Las características de los módulos acreditados deben
satisfacer los requisitos de las siguientes subsecciones para la
generación, almacenamiento y uso de las claves privadas.
4.2.1.1 Generación de Par de Claves
Si la aplicación necesita generar el par de claves del suscriptor, el
proceso de generación debe seguir los estándares adecuados para
el algoritmo seleccionado. Las aplicaciones deben utilizar algoritmos
de generación de claves reconocidos por la IOFE.
Las aplicaciones que generan claves deben usar una fuente
aleatoria para la generación de las claves. Las aplicaciones deben
usar un generador que cumpla los requisitos descritos en la
subsección 4.2.3.4.
Las claves privadas generadas para cifrado pueden ser almacenadas
en un repositorio de backup por parte de las ECs (Key Escrow)
conforme a las políticas que ellas establezcan para su acceso y
recuperación.
La generación de claves privadas sólo debe realizarse en un módulo
criptográfico FIPS 140-2 Nivel 1 para usuarios finales, Nivel 2 para
claves de ER y Nivel 3 para claves de EC.
- 37 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.1.2 Almacenamiento de Clave y Certificados Relacionados
Las aplicaciones deben proteger las claves privadas. Si la aplicación
desarrolla operaciones con la clave privada en el software, la
aplicación deberá cifrar la clave privada cuando no esté en uso. La
clave privada no cifrada debe existir en la memoria durante el
tiempo mínimo que fuere necesario para realizar operaciones de
clave privada. Todas las copias de la clave privada no cifrada deben
destruirse (por ejemplo, sobrescribiendo sobre ellas) cuando la
operación de la clave privada se haya completado.
Si el acceso o el uso de claves privadas es protegido a través de
contraseñas, la contraseña debe seleccionarse al azar desde un
espacio de por lo menos 256 posibles contraseñas (los módulos FIPS
acreditados ya cumplen con esto), a menos que existan medios
para detectar y proteger contra intentos deliberados de búsqueda
de las contraseñas.
Cuando las aplicaciones operan en sistemas en donde no existen
controles estrictos para otros programas de software que pueden
coexistir en el sistema, las aplicaciones deben proteger la clave
privada contra el uso subrepticio por parte de software malicioso.
Por ejemplo, la aplicación puede proporcionar al usuario una
interfaz que le informe que existe una solicitud pendiente de acceso
a la clave privada e identifique la aplicación que emite dicha
solicitud. Dicha interfaz debe proporcionar la posibilidad de permitir
o negar el uso de la clave.
Las aplicaciones, opcionalmente, pueden ser capaces de mantener
copias de las claves privadas de los pares de claves usadas para el
cifrado de información luego de producida la expiración de sus
correspondientes certificados con el propósito de descifrar cualquier
información residual que se encontrara cifrada.
Las aplicaciones deben ser capaces de mantener las claves públicas
o certificados de los pares de claves usados para firmar digitalmente
después de producida la expiración de sus correspondientes
certificados con el propósito de verificar las firmas en cualquier
información residual que se encontrara firmada.
- 38 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.1.3 Procesamiento de Entidades Acreditadas en la TSL.
La aplicación demostrará su habilidad de procesamiento de los
proveedores de servicios acreditados en la lista TSL considerando el
estándar ETSI TS102 231.
Sólo la AAC podrá contar con el software que le proporcione
capacidad para manejar (agregar, modificar o anular) y almacenar
los registros de los Prestadores de Servicios de Certificación Digital
(EC, ER, SVA) acreditadas.
4.2.1.4 Recuperación de Información
La aplicación –para el caso que especifique cumplir con esta
característica– solamente en el caso de certificados de cifrado,
brindará la capacidad para que individuos autorizados que han
recuperado una clave privada del sistema de gestión de
recuperación de claves de la IOFE, puedan descifrar la información
que la aplicación originalmente cifró.
4.2.1.5 Importación y Exportación de Claves
La IOFE soportará el Estándar de Sintaxis de Intercambio de
Información Personal PKCS#12, el cual es un estándar para
importar y exportar claves y los correspondientes certificados al
ambiente de manejo de claves de la aplicación.
4.2.2 Interfaz PKI
La aplicación podría tener que interactuar con una determinada PKI
para solicitar y obtener un certificado y almacenar la clave pública
del usuario de la aplicación, así como para obtener certificados para
comunicarse con otros suscriptores de la PKI. La sección 4.2.1.5
provee los requisitos de la aplicación para la importación y
exportación del par de claves del suscriptor y correspondientes
certificados.
4.2.2.1 Protocolos de Comunicación
Las aplicaciones deben emplear, según sea el caso, el Protocolo
Compacto de Acceso a Directorios (Lightweight Directory Access
Protocol –LDAP–), el Protocolo de Transmisión de Hipertexto
(HTTP), o el Protocolo de Transmisión de Hipertexto sobre SSL
(HTTPS).
4.2.2.2 Solicitud y Obtención de Nuevos Certificados para
Suscriptores
Las aplicaciones deben usar HTTPS para solicitar y obtener
certificados para el suscriptor.
- 39 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.2.3 Recuperación de Certificados
Muchas aplicaciones necesitan obtener o almacenar certificados
pertenecientes a otras entidades a efectos de interactuar o
comunicarse con ellos. Los terceros que confían (terceros usuarios)
necesitan certificados para obtener la clave pública de una entidad
con el propósito de desarrollar operaciones de clave pública.
Algunas aplicaciones pueden proporcionar métodos alternos para
obtener los certificados que se necesitan. Es necesario que la
aplicación incluya los certificados pertinentes en cada uno de los
mensajes firmados y, con eso, se evite tener que acceder a los
certificados del repositorio de certificados, sino sólo para conocer de
su estado.
4.2.3 Servicios de Cifrado
Las funciones de cifrado que una aplicación debe realizar dependen
de la aplicación. Las aplicaciones habilitadas para Clave Pública
tienen que ser capaces de ejecutar operaciones con las claves
públicas y privadas. En algunos casos, las aplicaciones tendrán que
realizar el cifrado simétrico o preparar previamente el mensaje
resumen porque generalmente las operaciones asimétricas no se
usan para información de gran tamaño. Los estándares describen
cómo operan los algoritmos individuales. Existen múltiples
estándares para algunos algoritmos31. Debido a que los algoritmos
operan generalmente en un tamaño fijo de bloques de datos, los
estándares normalmente establecen el método para llenar los datos
cuando el último bloque no está lleno. Las aplicaciones deben
utilizar algoritmos reconocidos por la IOFE y utilizar módulos
criptográficos certificados como mínimo con FIPS 140-2 Nivel 1 para
usuarios finales.
4.2.3.1 Servicios Asimétricos
Las aplicaciones deberán ser capaces de realizar operaciones de
clave pública necesarias para verificar firmas en objetos firmados
(certificados, CRLs, y respuestas OCSP, así como la lista TSL) de la
IOFE.
Las aplicaciones deben usar algoritmos incorporados en módulos
criptográficos acreditados.
31
Las variaciones involucran a menudo problemas tales como la generación de clave y convenciones
de relleno. Estas variaciones pueden conducir a incompatibilidades. Específicamente, existen
variaciones en el algoritmo RSA respecto a estos dos problemas. Las variaciones no son
inherentemente interoperables debido a las diferencias en las convenciones de relleno. Existen también
diferencias en el algoritmo Triple DES con relación al número de claves (2 o 3) usadas en las tres
aplicaciones del DES.
- 40 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.3.2 Servicios Simétricos
La necesidad de proporcionar los servicios simétricos es
dependiente de la aplicación. Las aplicaciones que soportan cifrado
generalmente necesitan las capacidades de cifrar grandes
volúmenes de información usando cifrado simétrico.
Las aplicaciones que interactúan con la IOFE utilizando SSL deben
ser capaces de cifrar y descifrar datos utilizando el Algoritmo de
Cifrado de datos Triple 3DES (Triple Data Encryption Algorithm TDEA) u cualquier otro reconocido por la IOFE.
Las aplicaciones que necesitan los servicios simétricos deben usar
los algoritmos incorporados en módulos criptográficos FIPS 140-2.
Las aplicaciones deben ser capaces de generar claves aleatorias de
cifrado simétrico mediante un generador de números aleatorios.
La Sección 4.2.3.4 contiene los requisitos para los generadores de
número aleatorios.
Las aplicaciones deben proteger las claves simétricas por el tiempo
de vida de su uso. Una clave no cifrada debe existir en memoria
durante el tiempo mínimo que sea necesario para desarrollar
operaciones usando dicha clave. Todas las copias de una clave no
cifrada deben ser destruidas (es decir, sobrescritas) cuando una
operación es completada. Las aplicaciones cifrarán las claves
cuando no estén en uso.
4.2.3.3 Servicios de Resumen
Los servicios de resumen proporcionan las funciones básicas para
crear mensajes resúmenes usados en aplicaciones que involucran
firma digital. Las aplicaciones deben utilizar algoritmos de resumen
reconocidos por la IOFE.
Las aplicaciones deben ser capaces de producir mensajes resumen
SHA para soportar la verificación de documentos electrónicos
firmados por la PKI de la IOFE.
Las aplicaciones deben usar mensajes resumen o algoritmos hash
(SHA) aprobados por el FIPS provistos en módulos certificados.
4.2.3.4 Generadores de Número Aleatorios
Un Generador de Número Aleatorio (RNG) es un componente crítico
en los servicios básicos de cifrado, que permite crear ambas claves
de cifrado, tanto simétricas como asimétricas.
- 41 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Las aplicaciones deben usar el algoritmo descrito en el [FIPS 186],
u otro reconocido por la IOFE, para generar los números aleatorios.
Las instancias individuales de una aplicación deben tener semillas
únicas y aleatorias para su RNG. La aplicación puede ser
configurada inicialmente con una semilla aleatoria única entre
instancias o generar una semilla aleatoria basada en eventos
aleatorios o valores en el ambiente operativo de la instancia.
4.2.4 Verificación del Estado del Certificado
La verificación del estado del certificado debe realizarse
previamente a los procesos de firma, autenticación o cifrado, de
manera obligatoria.
En el caso del proceso de firma digital, el resultado de la verificación
debe ser firmado digitalmente y almacenado como algún campo en
el mismo documento firmado. Las aplicaciones deben ser capaces
de solicitar y aceptar información con respecto al estado de los
certificados de los que depende la aplicación; actualmente existen
dos mecanismos generales para la verificación del estado: CRLs y
OCSPs. Las aplicaciones deben ser capaces de verificar el estado de
los certificados usando CRLs y, opcionalmente, pueden usar OCSPs
para verificar el estado del certificado.
Antes de realizar un proceso de firma, autenticación o cifrado, las
aplicaciones deben realizar lo siguiente:
a. Verificar que el certificado sirva para el fin especificado (firma
digital, autenticación o cifrado). No se puede utilizar
certificados de cifrado para realizar procesos de firma o
autenticación.
b. Verificar si el certificado ha expirado.
c. Verificar si el certificado ha sido (mediante algún mecanismo
OCSP, CRL, u otro estandarizado).
d. Desarrollar y procesar la ruta de certificación. Establecer la
acreditación del certificado digital, esto es que la EC emisora
se encuentre acreditada ante la AAC (mediante uso de la TSL
ETSI TS102.231).
Las aplicaciones deben almacenar los resultados de las
constataciones a), b) y c) en los campos respectivos e incluirlos
como extensiones del documento y firmarlos digitalmente como
parte del documento principal. Asimismo, se deberá almacenar la
validación de la ruta, lo cual implica la validación del estado de
acreditación de las EC implicadas en la emisión de dicho certificado.
Toda esta información debe ser firmada digitalmente por el propio
usuario.
- 42 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
En el
e.
f.
g.
h.
i.
Rev: 05/04-02-2008
Aprobado:
caso de los procesos de firma, opcionalmente, se puede:
Incorporar la razón por la que se firma el documento.
Permitir la declaración de la ubicación física del firmante.
Incorporar un comentario (campo adicional).
Incorporar la rúbrica digitalizada de la firma manuscrita.
Otros.
Sólo si las validaciones son satisfactorias se debe proceder a
realizar el proceso de firma, autenticación o cifrado, según
corresponda. Adicionalmente, se puede agregar la hora y fecha
cierta, empleando el estándar Time Stamping RFC 3161.
4.2.4.1 Procesamiento de las CRLs
Las aplicaciones deben ser capaces de obtener una CRL actual sin
necesidad de intervención del usuario, a fin de que sea usada para
verificar el estado de un certificado antes de realizar el proceso de
firma digital. Las aplicaciones con conectividad de red no habilitadas
para encontrar automáticamente los puntos de distribución CRL
deben ser capaces de ser configuradas con un punto de distribución
que la aplicación luego utilizará para obtener CRLs conforme lo
necesite. Las aplicaciones deben ser capaces de aceptar una CRL
para su empleo en la comprobación del estado del certificado.
4.2.4.2 Verificación del estado del Certificado mediante
respondedor OCSP
Las aplicaciones pueden opcionalmente emplear un respondedor
OCSP para verificar el estado de un certificado particular siempre
que la EC emisora o una tercera disponga del servicio. Las
aplicaciones deben preparar y transmitir la solicitud al respondedor
utilizando HTTP. La aplicación debe ser capaz de aceptar las
respuestas de OCSP.
4.2.4.3 Desarrollo de la Ruta y Procesamiento de la Ruta de la TSL
Las aplicaciones que soportan los procesos de verificación deben ser
capaces de desarrollar una ruta del certificado y el procesamiento
de dicha ruta, así como el procesamiento de la lista de Entidades
Acreditadas TSL según estándar ETSI TS 102 231. El proceso de
desarrollo de la ruta produce una secuencia de certificados que
conectan un certificado de la entidad final con un punto de
confianza y éste debe estar contenido en la TSL. El procesamiento
de la ruta determina la validez de la ruta en el contexto del uso
pretendido para el certificado de la entidad final.
- 43 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
4.2.4.3.1 Desarrollo de la Ruta
El desarrollo de la ruta involucra la recolección de los certificados y
su ordenamiento en una cadena desde un punto de confianza,
contenido en la TSL, hasta una entidad final. Las aplicaciones deben
construir las rutas automáticamente, sin intervención humana.
4.2.4.3.2 Procesamiento de la Ruta
Existen diversos pasos para desarrollar el procesamiento de la ruta
de certificación. Las aplicaciones deben realizar como mínimo los
pasos que se presentan a continuación, los cuales tienen que ser
desarrollados para cada certificado de la ruta:
•
•
•
•
Verificar las firmas del certificado. Esta verificación deberá
usar la clave pública del certificado del emisor.
Verificar que la fecha de realización del proceso de firma,
autenticación o cifrado se encuentre dentro del periodo de
vigencia del certificado.
Verificar que el uso del certificado es consistente con sus
extensiones (distinguir firma, autenticación y cifrado).
Verificar que el certificado no haya sido revocado.
El procesamiento de la ruta implica la verificación del certificado del
usuario final y de cada certificado que lo respalde, correspondientes
a las EC intermedias que participan en la emisión de dicho
certificado hasta llegar al certificado de la EC Raíz, la cual debe
encontrarse publicada en la TSL.
Previamente a ejecutar un proceso de firma, autenticación o cifrado,
se debe rechazar una ruta donde un certificado, ya sea
perteneciente a la entidad final, a una EC intermedia o a la EC Raíz,
haya tenido un resultado insatisfactorio en la revisión de alguno de
los certificados de que conforman dicha ruta.
4.2.4.4 Verificación del Estado de Revocación de un Certificado
El procesamiento de verificación del estado de revocación de un
certificado involucra la comprobación del estado de revocación de
los certificados que formen parte de su respectiva ruta de
certificación, a fin de asegurar que ninguno haya sido revocado. La
verificación del estado de revocación involucra el uso de una CRL o
un respondedor OCSP que no hayan expirado.
Existen diversos pasos que deben realizar las aplicaciones en el
procesamiento de una CRL, los cuales deben ser realizados para
cada certificado de la ruta o cadena:
- 44 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
•
•
•
Rev: 05/04-02-2008
Aprobado:
Verificar la firma en la CRL. Esta verificación requiere el
desarrollo y el procesamiento de una ruta de certificación que
establece que la EC emisora del certificado a verificar respalda
la confiabilidad de la CRL.
Verificar que la CRL no haya expirado si el certificado a
verificar no ha expirado. Una CRL ha expirado si la fecha
actual es posterior al próximo valor del campo de
actualización de la CRL.
Buscar la lista de certificados revocados para determinar que
el certificado a verificar no se encuentra incluido o su fecha de
revocación es posterior a la fecha actual.
La verificación del estado de revocación de un certificado para
aplicaciones que usan un respondedor OCSP involucra una serie
diferente de pasos. Las aplicaciones que usan respuestas de OCSP
deberán:
•
•
Verificar la firma en la respuesta OCSP. Esta actividad incluye
el desarrollo y procesamiento de una ruta de certificación que
establece que la EC emisora del certificado o un punto de
confianza respalda la confiabilidad del respondedor para el
propósito expreso de emisión de respuestas.
Verificar que la respuesta obtenida confirme la validez del
certificado.
Si la verificación del estado falla en cualquiera de las revisiones
anteriores, entonces la ruta deberá ser rechazada. Adicionalmente,
se debe verificar si la TSL incluye a la EC emisora del certificado
destino.
4.2.4.5 Procesamiento de la Extensión
Las aplicaciones deberán asegurar que el uso intencional del
certificado es consistente con las extensiones del mismo. Las
aplicaciones deben necesariamente procesar las extensiones críticas
y deben procesar asimismo las no críticas.
Las aplicaciones deben asegurar que en la extensión del Uso de la
Clave en el certificado de la entidad final se cumple lo siguiente:
•
•
•
•
El bit de la firma digital está activo para los usos de firma y
correo seguro.
El bit de autenticación está activo para el referido uso.
El bit de no repudio está activo para usos de no repudio.
El bit de cifrado de clave o el bit de cifrado de datos está
activo para usos de cifrado, dependiendo de si las claves o los
datos deberán ser cifrados.
- 45 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Las aplicaciones se asegurarán que para los certificados que
correspondan a la cadena de certificación, en la extensión del Uso
de la Clave, cumplan con lo siguiente:
•
•
•
El bit de la Firma de Certificado está activo en el certificado
que incluye la clave pública usada para firmar en el siguiente
certificado de la cadena.
El bit de la Firma de la CRL está activo en el certificado que
incluye la clave pública usada para firmar una CRL.
Las aplicaciones deben asegurar que la extensión
Restricciones Básicas es verdadera en el certificado que
incluye la clave pública empleada para firmar un certificado
subsecuente en la ruta.
4.3 Configuración de la Aplicación
Las aplicaciones deben estar firmadas empleando un certificado de
firma de código a fin de garantizar lo siguiente:
-
La autenticidad de la aplicación. Es decir, se puede comprobar
la identidad de la organización que distribuye el código
inspeccionando el nombre del titular del certificado con el que
se firma.
-
La integridad del código, para estar seguros de que es lícito y
no ha sido modificado de forma no autorizada después de
haber sido aprobado por el autor.
Las aplicaciones deben identificar todas las condiciones y
dependencias necesarias para que la aplicación realice sus funciones
de manera segura. Específicamente, las aplicaciones deben
identificar las dependencias en los soportes de los sistemas de
computación (por ejemplo, procesador, capacidad de memoria
primaria y secundaria), sistemas operativos (por ejemplo, número
de versión y edición), subsistemas (por ejemplo, herramientas de
criptografía).
Las aplicaciones deben ser configurables para operar con la IOFE y
deben operar automáticamente con ella, requiriendo la mínima
configuración posible. Deben ser capaces de autoconfigurarse y de
ser manejadas de manera centralizada, tanto como sea posible. Las
aplicaciones deben ser diseñadas para permitir una actualización o
modificación remota. Tales actualizaciones deben conservar la
seguridad. Los sitios de la red desde los cuales se realizan las
actualizaciones o modificaciones remotas deben ser autenticados o
dichas actualizaciones deben estar firmadas por una autoridad
confiable.
- 46 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Las aplicaciones deben ser capaces de ser configuradas para
operaciones seguras en los ambientes en que se desenvolverán.
Deben ser capaces de configuración automática y deben reportar
cualquier deficiencia que pueda evitar la realización de una
configuración completa. Asimismo, deben ser capaces de verificar
que el ambiente de operaciones está correctamente configurado y
reportar cualquier deficiencia.
Si las funciones automatizadas para configurar inicialmente, y como
consecuencia, mantener la configuración de la aplicación, no son
procedimientos factibles o prácticos, se requerirá de procedimientos
manuales para ser realizados por administradores y usuarios
finales. En este caso, las aplicaciones deben proporcionar
procedimientos que estén bien documentados y que sean fáciles de
seguir, asegurando que el administrador y el usuario instruidos
ejecutarán satisfactoriamente dichos procedimientos.
4.4 De los Sistemas de Intermediación Digitales
El Sistema de Intermediación Digital (SID) debe permitir:
•
•
•
•
•
•
Garantizar la autenticación de los usuarios.
Garantizar el no repudio de las transacciones electrónicas
realizadas y de los documentos generados de manera
individual (cada documento que se requiera tenga carácter no
repudiable deberá ser firmado individualmente).
Establecer un estricto control de acceso sobre la información
almacenada por el sistema.
Generar una bitácora digital que registre las transacciones
digitales realizadas por el sistema.
Ofrecer acuse de recibo por transacción realizada.
Generar domicilios electrónicos o utilizar cuentas de correo
electrónico de los usuarios finales para almacenar los
documentos generados como parte las transacciones digitales
realizadas. Cada documento adjunto en los mensajes de
correo electrónico debe estar firmado digitalmente.
4.5 Documentación de la Aplicación
Las aplicaciones deben incluir manuales de usuario y de
administrador (o equivalentes electrónicos) que instruya al personal
con poco conocimiento avanzado de criptografía de clave pública en
los usos y configuración apropiados y seguros de dicha aplicación.
Los documentos deberán incluir instrucciones para la configuración
de la aplicación a efectos de interoperar con la IOFE, lo cual incluye:
- 47 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
•
•
Rev: 05/04-02-2008
Aprobado:
Información sobre la TSL y los Proveedores de Servicios de
Certificación acreditados.
Políticas de Seguridad en el marco de la IOFE.
Asimismo, los documentos deben contener los procedimientos
necesarios para:
•
•
•
•
Generar un par de claves, solicitar y obtener certificados o
importar claves públicas y certificados ya existentes.
Seleccionar algoritmos de cifrado. Los manuales deben indicar
los algoritmos que deben, pueden y no pueden ser usados.
Configurar la aplicación para el acceso SSL si fuera necesario.
Otros.
Los documentos deberán instruir a los usuarios y administradores
respecto a sus responsabilidades como usuarios de PKI, lo cual
incluye:
•
•
•
Instrucciones en medidas técnicas y procedimentales para
proteger la clave privada contra el compromiso o mal uso.
Guía de las acciones a tomar cuando se sospecha que ha
habido compromiso de la clave (por ejemplo, cuando se ha
extraviado un token).
Otros.
- 48 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
5.0
Rev: 05/04-02-2008
Aprobado:
REQUISITOS DE CALIFICACIÓN
En esta sección son identificados los criterios empleados para
verificar que la aplicación de software cumple con los requisitos
técnicos. El propósito de la verificación es asegurar que la aplicación
pueda operar dentro de la IOFE y garantizar la seguridad en sus
operaciones. Las siguientes subsecciones describen los métodos de
verificación general, verificación de interoperabilidad y verificación
de seguridad. Los requisitos de interoperabilidad se enfocan en los
métodos usados para determinar si una aplicación es capaz de
interactuar con la IOFE. Los requisitos de seguridad identifican los
métodos que serán usados para determinar que una aplicación
protege adecuadamente la información que procesa y mantiene.
5.1 Métodos de Verificación
Cada requisito se verificará a través de uno de cuatro métodos:
Análisis, Demostración, Prueba o Inspección. Estos métodos están
definidos en la Tabla 4.
Tabla 4. Métodos de Verificación de Requisitos.
METODO
Demostración
DEFINICIÓN
Verificación del funcionamiento de toda o parte de la aplicación
donde se confía en la operación funcional observable y no
requiere del uso de instrumentación o de equipos de prueba
especiales.
Prueba
Verificación del funcionamiento de toda o parte de la aplicación
usando instrumentación o equipo especial de pruebas para
recolectar los datos para un análisis posterior.
Análisis
Evaluación del procesamiento de los datos acumulados
obtenidos de otros métodos de calificación. Los ejemplos son la
reducción, interpolación o extrapolación de los resultados de
prueba.
Inspección
Examen visual de los
documentación, etc.
componentes
de
la
aplicación,
5.2 Verificación de Interoperabilidad
Esta sección describe los procedimientos para verificar si una
aplicación es capaz de operar dentro de la IOFE. La Tabla 5
establece un acercamiento a la verificación para cada uno de los
requisitos relacionados a la interoperabilidad de la Sección 4.0. La
demostración enunciada y las actividades de prueba están referidas
dentro del marco de la IOFE.
- 49 -
la
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Tabla 5. Verificación de los Requerimientos.
Sección
4.2.1.1
Acercamiento de la Verificación
Generación de Pares de Claves.
Si la aplicación genera el par de claves del suscriptor, la aplicación
demostrará la habilidad para generar las claves, solicitar nuevos
certificados y obtener nuevos certificados a través de la interacción con
los PSC de la IOFE. Opcionalmente, si las claves generadas son para
aplicaciones de cifrado, la aplicación demostrará su capacidad para
proporcionar las claves a la entidad responsable de almacenarlas como
respaldo (backup). Se debe probar que la aplicación al menos permita
realizar la generación y el almacenamiento de la clave privada en un
módulo criptográfico que sea compatible con FIPS 140-2 Nivel 1 para
claves de usuarios finales,
4.2.1.3
Procesamiento de Entidades Acreditadas en la TSL.
La aplicación demostrará su habilidad de procesamiento de los
Proveedores de Servicios de Certificación acreditados en la lista TSL
según estándar ETSI TS 102 231 para la verificación de la cadena de
certificación del certificado a verificar.
4.2.1.4
Recuperación de Información.
La aplicación de software –para el caso que especifique cumplir con esta
característica–, solamente en el caso de certificados de cifrado, brindará
la capacidad para que individuos autorizados que han recuperado una
clave privada del sistema de manejo de recuperación de claves de la
IOFE, puedan descifrar la información que la aplicación originalmente
cifró.
4.2.1.5
Importación y Exportación de Claves.
Se debe demostrar la habilidad de la aplicación para importar las claves
asociadas con los certificados según el estándar x509v3 para individuos.
La aplicación importará por lo menos un juego de claves y certificados
para cada tipo de certificado (autenticación, firma, cifrado) soportado
por la aplicación.
La aplicación demostrará la habilidad para exportar claves y certificados.
La exactitud del archivo exportado se verificará a través del análisis.
4.2.2.1
Protocolos de Comunicación.
La aplicación probará –según sus propias especificaciones– la habilidad
de comunicarse utilizando los protocolos HTTP y HTTPS. Estas pruebas
pueden ser desarrolladas junto con otras demostraciones de su alcance.
4.2.4.1
Procesamiento de las CRLs.
La aplicación probará poseer la capacidad de procesar una CRL.
4.2.4.2
Verificación del estado del Certificado mediante un Respondedor OCSP.
Para el caso que la aplicación especifique cumplir con esta
característica, probará la capacidad de recuperar una respuesta OCSP.
El funcionamiento correcto puede ser verificado analizando los
resultados o a través de acciones demostrativas de la aplicación
posteriores al empleo de la respuesta. Si se usa el último, las
demostraciones mostrarán que la aplicación responde apropiadamente a
certificados válidos y revocados. La aplicación demostrará la capacidad
de obtener respuestas para certificados de todos los niveles de jerarquía
de la IOFE.
- 50 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Sección
4.2.4.3.2
Rev: 05/04-02-2008
Aprobado:
Acercamiento de la Verificación
Desarrollo de la Ruta.
Las aplicaciones deben demostrar que pueden construir las rutas
automáticamente sin la intervención humana.
4.2.4.3.2
Procesamiento de la Ruta.
Las aplicaciones deberán probar que, para cada certificado de la ruta de
certificación, pueden realizar lo siguiente:
•
•
•
•
Verificar las firmas del certificado. Esta verificación deberá usar
la clave pública del certificado del emisor.
Verificar que la fecha de realización del proceso de firma,
autenticación o cifrado se encuentre dentro del periodo de
vigencia del certificado.
Verificar que el uso del certificado es consistente con sus
extensiones (distinguir firma, autenticación y cifrado).
Verificar que el certificado no haya sido revocado.
Además, las aplicaciones deberán demostrar que, antes de realizar un
proceso de firma, autenticación o cifrado, realizan las verificaciones
mencionadas y de ser insatisfactorio el resultado de la verificación de
alguno de los certificados de la ruta, rechazarán dicha ruta y no se
podrá efectuar el proceso.
4.2.4.3.2
Procesamiento de la Ruta.
Las aplicaciones deberán demostrar que como parte de la verificación de
la ruta de certificación, también verifican el estado de la acreditación de
la EC Raíz a través de la lista TSL. Esta demostración puede determinar
el estado de la EC en la TSL y además en el contexto del procesamiento
de la ruta. La operación correcta de la aplicación será verificada
observando las respuestas o analizando la respuesta recibida por la
aplicación.
- 51 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Sección
4.2.4.3.2
Rev: 05/04-02-2008
Aprobado:
Acercamiento de la Verificación
Procesamiento de la Ruta.
Acerca de la firma digital: la aplicación de firma digital debe permitir la
realización de múltiples firmas digitales (cosign) en el mismo
documento electrónico, de manera recurrente. Los procesos de firma
digital deben de cumplir con las normas establecidas por la IOFE, los
estándares internacionales y de ser el caso, las normas referidas a la
generación de Microformas establecidas por el INDECOPI (Norma
Técnica Peruana), realizando al menos las siguientes verificaciones
antes de proceder a realizar la firma digital:
a. Constatar que el certificado sirva para el fin especificado (firma
digital, autenticación o cifrado).
b. Constatar la validez del certificado –su vigencia– antes de
proceder a la firma digital (mediante algún mecanismo OCSP,
CRL, u otro estandarizado).
c. Establecer la acreditación del certificado digital, esto es que la EC
emisora se encuentre acreditada ante la AAC (mediante uso de la
TSL ETSI TS102.231).
La aplicación deberá almacenar los resultados de las constataciones a),
b) y c) en los campos respectivos e incluirlos como extensiones del
documento y firmarlos digitalmente como parte del documento
principal.
Opcionalmente, la aplicación puede:
d. Incorporar la razón por la que se firma el documento.
e. Permitir la declaración de la ubicación física del firmante.
f. Incorporar un comentario (campo adicional).
g. Incorporar la rúbrica digitalizada de la firma manuscrita.
h. Otros.
En caso se especifique en la aplicación, se deberá agregar la hora y
fecha cierta, conforme al estándar Time Stamping RFC 3628 y el TimeStamp Protocol (TSP) RFC 3161.
4.2.4.3.2
Procesamiento de la Ruta.
Acerca de la verificación de la firma digital: la aplicación debe de
cumplir con las normas establecidas por la IOFE y los estándares
internacionales, realizando las siguientes acciones:
a. Constatar la integridad del documento firmado.
b. Leer y mostrar los campos considerados extensiones del
documento, para la verificación de la validez del certificado antes
de haber procedido a la firma digital: especificación del uso,
estado de revocación y acreditación del certificado.
c. Mostrar la fecha y hora cierta del documento generado, si fuera
el caso.
Opcionalmente:
d. Mostrar la razón por la que se firmó el documento.
e. Mostrar la declaración de la ubicación física del firmante.
f. Mostrar el comentario del firmante (campo adicional)
g. Mostrar la rúbrica digitalizada de la firma manuscrita.
h. Otros.
- 52 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Sección
0
Rev: 05/04-02-2008
Aprobado:
Acercamiento de la Verificación
Configuración de la aplicación.
La aplicación de software demostrará su capacidad para ser configurada
para su uso en el marco de la IOFE. Las pruebas de este requisito
también pueden involucrar inspecciones de los manuales del usuario y
del administrador.
0
De los Sistemas de Intermediación Digitales (SID).
a)
b)
c)
d)
e)
f)
El SID debe permitir la recepción de los archivos electrónicos por
Internet o líneas dedicadas para su registro almacenamiento y
conservación.
El SID debe almacenar/archivar los contenidos de las transacciones
(mensajes y archivos) enviados a su sistema
Los documentos electrónicos, si fuera el caso, serán creados con
valor legal de acuerdo al D.L 681.
Los documentos electrónicos que se generen contarán con:
• La seguridad e integridad del contenido y el soporte
electrónico.
• Almacenamiento y consulta de los documentos archivados
en línea.
• Si fuera el caso, la fecha y hora de la constancia de
recepción del intermediario –sujeto a estándares tipo RFC
Time Stamp– de los documentos electrónicos remitidos,
conforme al último párrafo del Artículo 8° del D.L. N° 681.
El SID debe proveer un medio de conexión de transacciones
seguras (canal SSL) y soporte para certificados digitales.
El Sistema de Intermediación Digital (SID) debe de:
• Contar con un dominio construido para la intermediación
digital.
• Generar una bitácora digital con valor legal.
• Asegurar que todo procesamiento sobre los documentos se
realicen on-line.
• Generar los elementos de pruebas necesarios para evitar el
no repudio de modo INDIVIDUAL de cada uno de los
mensajes y documentos enviados y recibidos.
• No debe limitarse al envío de correos electrónicos firmados
digitalmente, sino que debe garantizar que TODOS los
documentos electrónicos, productos de la transacción sean
INDIVIDUALMENTE firmados digitalmente (los adjuntos de
cada
correo
electrónico
deben
ser
firmados
individualmente, mientras que el cuerpo del correo sí puede
ser firmado empleando el estándar s-mime).
• Generar los acuses de recibo/de entrega de documentos
electrónicos y archivos.
- 53 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Sección
•
•
•
•
•
•
•
•
•
•
0
Rev: 05/04-02-2008
Aprobado:
Acercamiento de la Verificación
Firmar
digitalmente
los
documentos
electrónicos
independientemente de su extensión (DOC, PDF, XLS, JPG,
etc.). Estos documentos firmados digitalmente, en el caso
sea necesario, podrán ser adjuntados (attachment) como
parte de un correo firmado también digitalmente, en
formato s-mime.
Permitir la realización de múltiples firmas digitales (cosign)
en el mismo documento electrónico, almacenando
opcionalmente por cada una de ellas: razón por la firma,
ubicación, comentario, rúbrica, etc.
Realizar un estricto control de acceso a los usuarios al
sistema.
El sistema debe permitir al usuario autenticarse, ingresar a
su respectivo domicilio o correo electrónico y recibir sus
documentos electrónicos firmados digitalmente mediante
una sesión segura.
Permitir a través de una interfaz desde el SID, el acceso de
los usuarios a sus mensajes “legalizados”.
Proveer
el
almacenamiento
de
las
transacciones
electrónicas, documentos electrónicos y archivos tipo logs.
Mantener el registro, almacenamiento y la custodia
certificada de los mensajes intercambiados entre las partes.
Recibir los mensajes y archivos electrónicos generados por
las partes.
Registrar los datos del remitente, destinatario, fecha, hora,
asunto, hora cierta (si fuera el caso, , conforme al estándar
Time Stamping RFC 3628 y el Time-Stamp Protocol (TSP)
RFC 3161) y almacenar el documento de forma automática.
En el caso del servicio de microformas, el sistema debe
permitir almacenar en línea los documentos para su
consulta en línea por un período determinado de tiempo.
Pasado este tiempo se conservarán sólo en medios
removibles (por ejemplo: discos ópticos, DVD/CDs) y en
una bóveda certificada de medios seguros.
De los Sistemas de Intermediación Digitales (SID).
Acerca de los modos de Autenticación en el SID: los usuarios del SID
deben de ser autenticados por alguno de los dos mecanismos
siguientes:
a. Doble Factor de Autenticación: Usando un certificado digital
(almacenado en un dispositivo físico certificado con FIPS 140-2)
y la contraseña de acceso a la clave privada. En caso la
autenticación sea satisfactoria, se debe proceder a un inicio de
sesión seguro estableciendo un canal seguro de comunicación
mediante el protocolo SSL.
b. Triple Factor de Autenticación: incorporando al mecanismo
anterior alguna tecnología biométrica de autenticación del
usuario o las partes.
- 54 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Sección
0
Rev: 05/04-02-2008
Aprobado:
Acercamiento de la Verificación
De los Sistemas de Intermediación Digitales (SID).
Acerca de los modos de generación de documentos firmados
digitalmente en el SID: una vez realizada la autenticación, el SID debe
al menos permitir los siguientes modos de generación de documentos
firmados digitalmente:
a. Un documento de cualquier extensión debe poder ser firmado
digitalmente por el usuario provisto de certificados digitales y ser
cargado al servidor del sistema de intermediación haciendo uso
de un canal seguro (SSL).
b. Debe
permitir
generar
correos
electrónicos
firmados
digitalmente, esto es, correo seguro en formato s-mime,
especialmente para los acuses de recibo y siendo cada
documento adjunto firmado digitalmente.
0
De los Sistemas de Intermediación Digitales (SID).
Acerca de modos de generación de acuses de recibo: se pueden
emplear domicilios o correos electrónicos propios del usuario. En caso se
empleen correos electrónicos, los acuses deben estar en formato smime y los documentos electrónicos adjuntos (attachment) deberán
estar firmados digitalmente de manera individual.
0
De los Sistemas de Intermediación Digitales (SID).
Acerca de los modos de verificación de los documentos firmados
digitalmente: el proveedor del SID debe de proveer las herramientas
necesarias para realizar los siguientes tipos de verificación de los
documentos firmados digitalmente:
a. Verificación On-line: Los documentos firmados digitalmente
pueden ser verificados dentro del mismo SID.
b. Verificación Off-Line: Se requiere un software desktop que
se ejecute en los ordenadores de los usuarios del SID que
les permita verificar off-line los documentos firmados
digitalmente.
4.5
Documentación de la Aplicación.
Estos requisitos serán verificados por la inspección de los manuales y
por una demostración de la aplicación que se realizará conforme haya
sido documentado, en caso se requiera orientación para la
configuración.
5.3 Verificación de la Seguridad
La verificación de la seguridad de una aplicación tiene varias
variables. Las variables incluyen la funcionalidad que la aplicación
proporciona y la arquitectura e implementación del diseño de la
aplicación. Debido a esta variabilidad, esta sección no proporciona
en detalle los requisitos de comprobación de forma similar a la
sección anterior. El uso de módulos criptográficos evaluados por el
FIPS 140-2 simplificará los requisitos y actividades de la verificación
de la seguridad de la aplicación.
- 55 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
ANEXO A:
FORMULARIOS DE EVALUCIÓN DE LA APLICACIÓN DE
SOFTWARE.
Se presentan los siguientes formularios (28 en total) que sirven para
tal fin. Las aplicaciones de usen componentes (librerías) acreditados
con FIPS ya cumplen con diversos requerimientos establecidos aquí;
sin embrago, deben demostrar el manejo conveniente de esas
librerías conforme a lo exigido en los siguientes formularios.
- 56 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 1
Resultados de la prueba de interoperabilidad de la APLICACIÓN
CRITERIO
GENERACIÓN DE PAR DE CLAVES (para aplicaciones que generen claves)
- Claves del suscriptor
- Generación del par de claves
USO DE LA TSL (en la medida que se encuentre implementada por la AAC)
- Uso de la TSL
RECUPERACIÓN DE INFORMACIÓN
- Recuperación de Información
IMPORTACIÓN Y EXPORTACIÓN DE CLAVES Y CERTIFICADOS
- Importación de claves y certificados
- Tipos de certificados
- Exportación de claves y certificados
VERIFICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN
- Verificación de los protocolos de comunicación
REVISIÓN DEL ESTADO DEL CERTIFICADO
- Verificación del Estado del Certificado (CRL)
- Verificación del Estado del Certificado (Respondedor OCSP)-Opcional
RECUPERACIÓN DE CERTIFICADOS Y LISTAS DE CERTIFICADOS REVOCADOS
- Certificados y CRLs
- Recuperación de las claves de cifrado (opcional)
DESARROLLO Y PROCESAMIENTO DE LA RUTA
- Desarrollo y procesamiento de la ruta
VERIFICACIÓN DEL ESTADO DEL PROVEEDOR DE SERVICIOS DE CERTIFICACIÓN
- Verificación del Estado mediante la lista TSL
FIRMA DIGITAL
- Comprobación de funcionalidades
VERIFICACIÓN DE LA FIRMA DIGITAL
- Comprobación de funcionalidades
CONFIGURACIÓN DE LA APLICACIÓN
- Aplicación firmada empleando un certificado de firma de código
- Configuración de la aplicación
SISTEMA DE INTERMEDIACIÓN DIGITAL SID
- Comprobación de funcionalidades
- Modos de autenticación
- Modos de generación de documentos firmados digitalmente
- Modos de generación de acuses de recibo
- Modos de Verificación de los documentos firmados digitalmente
DOCUMENTACIÓN DE LA APLICACIÓN
- Manuales de usuario y administrador
- Configuración para la interoperabilidad
- Responsabilidades como usuarios de la Infraestructura de Clave Pública (PKI)
- 57 -
RESULTADO
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 2
FORMULARIO DE RECOLECCIÓN DE DATOS - INFORMACIÓN DETALLADA PARA LA PRUEBA DE LA APLICACIÓN
Nombre de la Aplicación:_________________________________Versión:___________________________________
Proveedor: _______________________________________
Evaluadores (Recolectores de Datos/Operadores): __________________ __________________ __________________
Lugar(es) de la prueba: _________________________Fechas de la prueba:_______________ hasta________________
DATOS DE PRUEBA COMUN
Hardware y sistema operativo para todos los sistemas:
Versiones de software y actualizaciones para todas las aplicaciones:
Equipo de prueba adicional requerido:
Direcciones IP usadas:
Certificados de firma de código usados (Incluye contraseñas de certificado):
Archivos usados:
Passwords Usados:
Comentarios/Notas:
Diagrama de Prueba de red:
- 58 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 3 (Opcional)
FORMULARIO DE RECOLECCIÓN DE DATOS – GENERACIÓN DEL PAR DE CLAVES
Claves del Subscriptor: Generación de claves, solicitud de nuevos certificados, y obtención de
nuevos certificados a través de la interacción con la IOFD.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluadores (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 59 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 4 (Para aplicaciones con generación de claves)
FORMULARIO DE RECOLECCIÓN DE DATOS – GENERACIÓN DEL PAR DE CLAVES
Generación del Par de Claves: Generación de pares de claves usando un algoritmo estándar
reconocido por la AAC para la acreditación.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluadores (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
- 60 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 5 (En la medida que la TSL esté implementada por la AAC)
FORMULARIO DE RECOLECCIÓN DE DATOS – USO DE LA TSL
Uso de la TSL: Procesamiento de los proveedores de servicios acreditados en la lista TSL
según estándar ETSI TS 102 231.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 61 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Formulario 6
Rev: 05/04-02-2008
Aprobado:
(Opcional para certificados de cifrado)
FORMULARIO DE RECOLECCIÓN DE DATOS – RECUPERACIÓN DE INFORMACIÓN
Recuperación de Información: Uso de una clave privada recuperada del sistema de manejo
de recuperación de claves de la IOFE.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
- 62 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 7 (Para aplicaciones propietarias que no utilizan la
funcionalidad del sistema operativo)
FORMULARIO DE RECOLECCIÓN DE DATOS – IMPORTACIÓN Y EXPORTACIÓN DE CERTIFICADOS
Importación de Claves y Certificados: Importación de claves asociadas con certificados
estandarizados para individuos.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 63 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 8 (Para aplicaciones propietarias que no utilizan la
funcionalidad del sistema operativo)
FORMULARIO DE RECOLECCIÓN DE DATOS – IMPORTACIÓN Y EXPORTACIÓN DE CERTIFICADOS
Tipos de Certificados: Importación de por lo menos un conjunto de claves y certificados para cada
tipo de certificado que soporta.
Nombre de la Aplicación:______________________
Resultado:
Aprobado
Fallido
Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 64 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 9 (Para aplicaciones propietarias que no utilizan la
funcionalidad del sistema operativo)
FORMULARIO DE RECOLECCIÓN DE DATOS – IMPORTACIÓN Y EXPORTACIÓN DE CERTIFICADOS
Resultado:
Exportación de Claves y Certificados
Nombre de la Aplicación:______________________
Aprobado
Fallido
Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 65 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 10 (Para SID y aplicaciones con generación de certificados)
FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN
Verificación de los Protocolos de Comunicación: Comunicación con la IOFE usando un
protocolo LDAP, HTTP o HTTPS.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 66 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 11
FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DEL ESTADO DEL CERTIFICADO
Verificación del Estado del Certificado (CRL): Capacidad de recuperar la CRL actual.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
DESIGNADOR
RESULTADO DE
VALIDACIÓN
ESPERADO
RL.02.01
RL.03.01
RL.05.01
RL.06.01
RL.07.01
RL.08.01
RL.09.01
FRACASO
FRACASO
FRACASO
FRACASO
FRACASO
FRACASO
FRACASO
RL.03.02
RL.03.03
RL.05.02
RL.06.02
RL.07.02
RL.07.03
FRACASO
ÉXITO
FRACASO
FRACASO
FRACASO
ÉXITO
RESULTADO ACTUAL
PRUEBAS DE NIVEL 1
PRUEBAS DE NIVEL 2
- 67 -
COMENTARIOS
APROBADO
O
FALLIDO
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 12 (Opcional)
FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DEL ESTADO DEL CERTIFICADO
Verificación del Estado del Certificado (Respondedor OSC): Capacidad de recuperar una
respuesta OSC.
Nombre de la Aplicación:______________________
Resultado:
Aprobado
Fallido
Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
EVENTO DE PRUEBA
ACCIÓN DEL RECOLECTOR DE DATOS
- 68 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 13 (En la medida que la TSL esté implementada por la AAC)
FORMULARIO DE RECOLECCIÓN DE DATOS – DESARROLLO Y PROCESAMIENTO DE RUTA
Desarrollo y Procesamiento de Ruta: Capacidad de desarrollar la ruta del certificado y su
procesamiento, así como el procesamiento de la lista TSL.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
- 69 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 14 (En la medida que la TSL esté implementada por la AAC)
FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DEL ESTADO DEL PROVEEDOR DE SERVICIOS DE CERTIFICACIÓN
Verificación del Estado del proveedor de servicios de certificación mediante la lista
TSL
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
- 70 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 15
FORMULARIO DE RECOLECCIÓN DE DATOS – FIRMA DIGITAL
Comprobación de funcionalidades: Cosign, normas de la IOFE y estándares. Realización de
verificaciones antes de la firma.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
- 71 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 16
FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DE LA FIRMA DIGITAL
Comprobación de funcionalidades: Normas de la IOFE y estándares. Acciones:
constatación de integridad, visualización de extensiones y fecha y hora cierta (opcional) del
documento.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
1
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
EVENTO
Garantizar el no repudio e integridad del
documento firmado
Notas:
Visualización de extensiones
2
Notas:
3
Garantizar que se utiliza el estándar
Time Stamp RFC 3161 para establecer
la fecha y hora cierta
Notas:
- 72 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 17
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - CONFIGURACIÓN DE LA APLICACIÓN
Configuración de la Aplicación: Uso de la aplicación en el marco de la IOFE.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
Asegurar que la (APLICACIÓN) está configurada
para operar en el marco de la IOFE
1
Notas:
2
Garantizar la autoría e integridad de la
(APLICACIÓN): uso de un certificado de firma de
código.
Notas:
3
Asegurar que la (APLICACIÓN) ha identificado las
condiciones de operación requeridas de su
entorno de operación.
Notas:
4
Asegurar que la (APLICACIÓN) ha identificado
todas las condiciones necesarias y dependencias
para una ejecución segura de sus funciones.
Notas:
Asegurar que la (APLICACIÓN) está configurada
para una operación segura en su medio.
5
Notas:
6
Asegurar que la (APLICACIÓN) brinda
características que satisfacen los Requerimientos
Mínimos de la IOFE. Cuando esto no es posible,
asegurar que la (APLICACIÓN) brindó
procedimientos bien documentados y fáciles de
seguir y asegurar que el administrador
Notas:
7
Asegurar que la (APLICACIÓN) es capaz de
llegar a ser configurada para operar con los
puntos de confianza de la IOFE.
Notas:
- 73 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 18
FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID
Comprobación de funcionalidades: Trabajo on line, seguridad, cumplimiento del DL 681.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
1
Notas:
2
Notas:
3
Notas:
4
- 74 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 19
FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID
Modos de autenticación: Comprobación de los dos mecanismos previstos.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
Doble Factor de Autenticación
1
Notas
Triple factor de Autenticación
2
Notas
- 75 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 20
FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID
Modos de generación de documentos firmados digitalmente: Comprobación de los dos
mecanismos previstos.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
1
ACCIÓN DEL RECOLECTOR DE DATOS
Documento de cualquier extensión
firmado y cargado al servidor del
Sistema de Intermediación
Notas:
Generación de correo electrónico
seguro, formato s-mime
2
Notas:
- 76 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 21
FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID
Modos de generación de acuses de recibo: Comprobación de los dos mecanismos
previstos.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
Domicilio electrónico
1
Notas:
Correo electrónico
2
Notas:
- 77 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 22
FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID
Modos de Verificación de los documentos firmados digitalmente: Comprobación de los
dos mecanismos previstos.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usados (si aplica):
Anomalías:
Resultados/Notas:
EVENTO DE PRUEBA
EVENTO
ACCIÓN DEL RECOLECTOR DE DATOS
Verificación On-line
Notas:
Verificación Off-line
Notas:
- 78 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 23
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN
Manuales de Usuario y Administrador: Instrucción al personal poco familiarizado con la
criptografía de clave pública, configuración apropiada y segura para el uso de la aplicación.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
Información de la prueba:
Asegurar que la APLICACIÓN incluyó manuales de usuario y administrador (o sus equivalentes electrónicos) que son
adecuados para instruir a personal poco familiarizado con criptografía de clave pública en la configuración y uso apropiados
y seguros de la aplicación.
EVENTO
EVENTO DE PRUEBA
1
Las instrucciones contemplan políticas
de seguridad en el marco de la IOFE.
2
Las instrucciones contemplan el empleo
del TSL.
3
Las instrucciones contemplan la
generación del par de claves y solicitud
y obtención de certificados o la
importación de claves y certificados
existentes.
4
Las instrucciones contemplan la
interoperabilidad con certificados x509v3
de diversos proveedores acreditados o
no.
5
Las instrucciones contemplan la
selección o uso de los algoritmos de
cifrado. Las selecciones deben indicar
los algoritmos que deben, pueden o no
pueden ser usados.
6
Las instrucciones contemplan la
configuración de la aplicación para
acceso SSL a la IOFE, si fuera
necesario.
ACCIÓN DEL RECOLECTOR DE DATOS
- 79 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 24
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN
Configuración para la Interoperabilidad: Instrucciones de configuración para interoperar con
la IOFE.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
ACCIÓN DEL RECOLECTOR DE DATOS
EVENTO DE PRUEBA
EVENTO
1
Notas:
2
Notas:
3
Notas:
- 80 -
RESULTADOS
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 25
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN
Responsabilidades con usuarios de la PKI: Instrucción a usuarios y administradores.
Resultado:
Aprobado
Fallido
Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
Información de la prueba:
Asegurar que la documentación de la APLICACIÓN instruye a usuarios y administradores en relación a sus
responsabilidades como usuarios de la PKI.
EVENTO
EVENTO DE PRUEBA
1
Los documentos de la APLICACIÓN
contienen instrucciones sobre medidas
técnicas o procedimentales para
proteger la clave privada contra
compromiso y uso inapropiado.
2
Los documentos de la APLICACIÓN
contienen una guía de acciones a tomar
en caso de sospecha de compromiso de
clave (por ejemplo: un token extraviado).
ACCIÓN DEL RECOLECTOR DE DATOS
- 81 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 26
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN
Resultado:
Cumplimiento de los requerimientos de Usabilidad.
Nombre de la Aplicación:______________________
Aprobado
Fallido
Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________
Ubicación: ____________________________________ Fecha:_______________________________
DATOS DE PRUEBA ESPECÍFICOS
Software usado para la prueba:
Equipo usado para la prueba:
Certificados usados (si aplica):
Archivos usado (si aplica):
Anomalías:
Resultados/Notas:
Información de la prueba:
Asegurar que la APLICACIÓN cumpla con los requerimientos de Usabilidad.
Se deberá garantizar que se brinde la información básica de manera adecuada y los sistemas de ayuda necesarios.
- 82 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN
(Continuación)
EVENTO
EVENTO DE PRUEBA
1
Requerimiento Técnico:
Posibilidad de instalación y operación con
hardware y software existente.
2
Requerimiento Técnico:
Posibilidad de ser soportados en múltiples
sistemas operativos.
3
Requerimiento Técnico:
Informe al usuario de los programas
adicionales requeridos para la instalación.
4
Instalación y Configuración:
Facilidad de adapción de la configuración
a necesidades individuales.
5
Instalación y Configuración:
Proceso sencillo de instalación y
configuración, tal que ejecutarlos de
manera exitosa desde la primera vez.
6
Instalación y Configuración:
Cuenta con una guía de instalación y
configuración.
7
Soporte Técnico:
Disponibilidad de dirección electrónica o
número telefónico de contacto y
disponibilidad de horario.
8
Uso de la aplicación:
Disponibilidad de mensajes de ayuda
durante una operación.
9
Uso de la aplicación:
Presentación de mensajes de peligro si
se está ejecutando una operación
sensible respecto de la seguridad.
10
Uso de la aplicación:
Características de seguridad
comprensibles para los usuarios.
11
12
ACCIÓN DEL RECOLECTOR DE DATOS
Uso de la aplicación:
Organización de los diálogos y menús de
fácil uso. Uso de términos técnicos
adecuados e inteligibles.
Uso de la aplicación:
Características por defecto en función de
los requerimientos de un usuario
ordinario.
13
Normatividad:
Presentación de mensajes referidos a las
consecuencias legales vinculadas.
14
Idioma:
Toda la información y los ejemplos son
presentados en español.
- 83 -
RESULTADOS
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
Formulario 27 (En la medida que la TSL esté implementada por la AAC)
REPORTE VERIFICACIÓN DE CONFORMIDAD DEL EMPLEO DE TSL ETSI TS102.231
Nombre de la Aplicación: ______________________
FECHA ___ / ___ / ___
Versión: __________
Evaluador(es) (Recolectores de Información/Operador
____________________
____________________
Lugar(es) de la prueba:
____________________
____________________
Información del Reporte:
Reporte Completado por: ______________________________
- 84 -
Fecha : __ / __ / __ Hora: _________
Rev: 05/04-02-2008
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Aprobado:
Formulario 28
REPORTE DIARIO DE ESTADO DE PRUEBA
Nombre de la Aplicación: ______________________
FECHA ___ / ___ / ___
Versión: __________
Evaluador(es) (Recolectores de Información/Operador
____________________
____________________
Lugar(es) de la prueba:
____________________
____________________
Pruebas completadas el día de hoy:
Pruebas esperadas para ser completadas el día de mañana:
Anomalías:
Resultados/Notas:
Información del Reporte:
Reporte Completado por: ______________________________
- 85 -
Fecha : __ / __ / __ Hora: _________
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Rev: 05/04-02-2008
Aprobado:
ANEXO B:
ESTÁNDARES RECONOCIDOS PARA LA
ACREDITACIÓN
Referencia
Descripción
EC/PKI
X.509 V3
Formatos Estándar para Certificados de Claves Públicas
X.500, X.501,
X.509, X.521
Formatos de Nombres para Certificados de Claves Públicas
ANSI X9.31,
FIPS 186-2
Algoritmos Asimétricos RSA
ANSI X9.62, FIPS
186-2
Algoritmos Asimétricos Elliptic Curve DSA
RSA 1024/2048
bits
Soporte para capacidades de longitud de Clave
FIPS 46
Estándar de Cifrado de Datos (DES)
FIPS 180-2
Algoritmo de Hashing SHA-1, SHA-224, SHA-256, SHA-384,
SHA-512
FIPS 186-2
Estándar de Firma Digital (DSA)
NIST 800-67,
NIST 800-38A,
ANSI X9.52-1998
CBC Simétrico Triple DES
FIPS 185,
SKIPJACK and
KEA Algorithm
Specifications
(Version 2.0)
Algoritmo de cifrado simétrico SKIPJACK
Algoritmo de intercambio de claves KEA
FIPS 197
Estándar de Cifrado Avanzado (AES)
CWA 14167 (1-4)
Gestión de Sistemas EC de Confianza
CWA 14172 (1-8)
Conformidad con las Directivas CEN para apropiación y
operación de EC
CWA 14355
Dispositivos de Creación de Firma Segura
CWA 14365 (1-2)
Uso de las Firmas Electrónicas: Aspectos legales y técnicos
CWA 14890 (1-2)
Interfaz de aplicación para tarjetas inteligentes utilizadas como
Dispositivos de Creación de Firma Segura
ETSI SR 002 176
Infraestructuras y Firmas Electrónicas (ESI) – Algoritmos y
Parámetros para Firmas Electrónicas Seguras
ETSI TS 101 861
Perfil de Estampa de Tiempo
ETSI TS 102 023
Infraestructuras y Firmas Electrónicas (ESI) – Requisitos de
Política para Autoridades de Time-Stamping
- 86 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Referencia
Rev: 05/04-02-2008
Aprobado:
Descripción
ETSI TS 102 040
Infraestructuras y Firmas Electrónicas (ESI) – Armonización
Internacional de Requisitos de Política para ECs emisoras de
Certificados
ETSI TS 102 042
Requisitos de Política para Entidades de Certificación que
emiten Certificados de Clave Pública
ETSI TS 102 280
X.509 V.3 Perfil de Certificado para Certificados emitidos a
Personas Naturales
IETF RFC 373
Juegos de Caracteres Arbitrarios
IETF RFC 1422
Sólo lo relacionado a certificados en general, gestión de claves
y Lista de Revocación de Certificados [CRL]
IETF RFC 2459
Certificado y Perfil CRL X.509 para PKI
IETF RFC 2560
Protocolo OCSP (Protocolo de Estado de Certificado en Línea)
X.509 para PKI
IETF RFC 3280
Certificado y Perfil CRL X.509 para PKI
IETF RFC 3039
Perfil de Certificados Calificados X.509 para PKI
IETF RFC 3629
RFC 3629 - UTF-8, un formato de conversión, formato de la
norma ISO 10646
IETF RFC 3647
Sistema básico de Política de Certificados y Prácticas de
Certificación X.509 para PKI
ISO 27001
Metodología, Transferencia del Conocimiento y Servicio
ISO 15408
Tecnología de la Información — Criterios de Evaluación de
Técnicas de Seguridad para TI
ISO/IEC TR13335
Tecnología de la Información — Guías para la gestión de la
Seguridad TI — Directrices respecto al tipo de controles que
deben ser implementados y deben ser especificados por una
EC
PKCS#1
Estándar de Criptografía RSA: define la criptografía RSA
PKCS#3
Estándar de Acuerdo de Clave Diffie-Hellman
PKCS#5
Estándar de Criptografía basada en Contraseña: define cómo
cifrar y descifrar datos usando contraseñas
PKCS#7
Estándar de Sintaxis de Mensaje Criptográfico: describe una
sintaxis general para datos que puedan tener criptografía
aplicada en sí mismos, tales como firmas digitales y sobres
digitales
PKCS#8
Estándar de Sintaxis de Información de Clave Privada: describe
una sintaxis para información de clave privada donde ésta
incluye una clave privada para algún algoritmo de clave pública
y un conjunto de atributos
PKCS#9
Clases de Objetos Seleccionados y Tipos de Atributos: define
dos nuevas clases de objetos auxiliares, pkcsEntity y
naturalPerson, y también tipos de atributos para usarse con
estas clases
- 87 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Referencia
Rev: 05/04-02-2008
Aprobado:
Descripción
PKCS#10
Estándar de Sintaxis de Solicitud de Certificación: describe la
sintaxis para una solicitud de certificación donde ésta consista
de un nombre distinguido, una clave pública y, opcionalmente,
un conjunto de atributos, firmados colectivamente por la entidad
que solicita la certificación
PKCS#11
Estándar de Interfaz de Token Criptográfico: especifica una
interfaz de programación de aplicación (API), denominada
“Cryptoki”, para dispositivos que contengan información
criptográfica y realicen funciones criptográficas
PKCS#12
Sintaxis de Intercambio de Información Personal: describe una
sintaxis de transferencia para información de identidad
personal, incluyendo claves privadas, certificados, secretos
misceláneos y extensiones
PKCS#15
Se aplica en realidad a proveedores de tarjetas inteligentes
RFC 2527
Lineamientos para Declaración de Prácticas de Certificación
[CPS] y Políticas de Certificados [CP]
RFC 2587
Diagrama LDAPv2 X.509 para PKI
RFC 2818
HTTP sobre TLS
IETF RFC 3379
Requisitos para Validación de Ruta Delegada y para el
Protocolo de Descubrimiento de Ruta Delegada
TIA - 942
Estándar de la Infraestructura de Telecomunicaciones para
Centros de Datos
FIPS 140-2 Anexo
C
Generadores de Números Aleatorios (RNG)
NIST SP 800-90
Generadores determinísticos de Bit Aleatorios (DRBG)
MAC
NIST SP 800-38B
Algoritmo MAC basado en cifrado de bloques (CMAC)
NIST SP 800-38C
Contador con modo de encadenamiento de bloques cifrados
(Counter Cipher-block chaining mode -CCM)
FIPS 198
Suma de chequeo para corroborar la integridad de los datos
(Keyed- Hashing for Message Authentication)
HSM
FIPS 140
Requisitos de Seguridad para Módulos Criptográficos: hardware
y firmware
Tarjetas
inteligentes
Validación FIPS
140-2
Requisitos de Seguridad para Módulos Criptográficos: hardware
y firmware
Compatibilidad
ISO 7816 1-5
Microcontrolador y Unidad de Procesamiento Numérico (NPU)
suplementario capaces de calcular operaciones criptográficas
acordes con PKCS #11 y PKCS #15, de conformidad con los
requisitos del ISO/IEC 7816-1 al 7816-5
- 88 -
Infraestructura Oficial de Firma
Electrónica IOFE PERU
Referencia
Rev: 05/04-02-2008
Aprobado:
Descripción
Procesador
criptográfico
de 32 bits
Para ejecución y usabilidad mejoradas de la tarjeta
Soporte para RSA
de 1024/2048 bits
Capacidades de longitud de Clave
Soporte para
algoritmo DES
Algoritmo Simétrico
Soporte para
algoritmo 3DES
Algoritmo Simétrico
Software CSP
Proveedor de Servicios Criptográficos [CSP] en el SO del chip
capaz de ejecutar funciones criptográficas
Certificación
FIPS 140-2
Nivel 3
Para HSM, nivel total alcanzado
Certificación EMC
Para lector de tarjeta inteligente
Certificación
ISO 27001
Del entorno
Otros
RFC 3161
Protocolo de Sello de Tiempo (TSP) X.509 para PKI
RFC 3628
Requerimientos de Políticas para Autoridades de Sello de
Tiempo (TSAs)
RFC 2246
Protocolo TLS
RFC 2510
Protocolos de Administración de Certificados X.509 para PKI
RFC 2630
Sintaxis para Mensajes Criptográficos
RFC 2634
Optimización de los Servicios de seguridad para S/MIME
RFC 1231
Algoritmo de Hashing MD5
RFC 3126
Formato de firma electrónica para formas electrónicas a largo
plazo
- 89 -