guía de acreditación de aplicaciones de software · 4.2.1 manejo de claves ... los documentos...

- 1 -

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

- 2 -

Rev: 05/04-02-2008

Infraestructura Oficial de Firma Electrónica IOFE PERU 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.

- 3 -

Rev: 05/04-02-2008


ÍNDICE GENERAL

1. INTRODUCCIÓN .................................................................................................................... 5 1.1 PROPÓSITO ........................................................................................................................... 5 1.2 DE LAS APLICACIONES (SOFTWARE) DE FIRMA DIGITAL ................................................. 6 1.3 DE LOS SISTEMAS DE INTERMEDIACIÓN DIGITALES ........................................................ 7 1.4 PÚBLICO AL QUE VA DIRIGIDO .......................................................................................... 10 1.5 VISIÓN GENERAL ............................................................................................................... 10

2.0 ANTECEDENTES .............................................................................................................. 19

3.0 DOCUMENTOS APLICABLES Y ALCANCES ........................................................ 31

3.1 DOCUMENTOS APLICABLES ............................................................................................... 31 3.2 NIVELES DE SEGURIDAD DE PKI ...................................................................................... 33

4.0 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

4.2.3 Servicios de Cifrado ........................................................................................... 40 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

4.2.4 Verificación del Estado del Certificado ........................................................ 42 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.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

4.3 CONFIGURACIÓN DE LA APLICACIÓN ................................................................................ 46 4.4 DE LOS SISTEMAS DE INTERMEDIACIÓN DIGITALES ...................................................... 47 4.5 DOCUMENTACIÓN DE LA APLICACIÓN............................................................................... 47

- 4 -

Rev: 05/04-02-2008


5.0 REQUISITOS DE CALIFICACIÓN ................................................................................... 49

5.1 MÉTODOS DE VERIFICACIÓN............................................................................................. 49 5.2 VERIFICACIÓN DE INTEROPERABILIDAD ........................................................................... 49 5.3 VERIFICACIÓN DE LA SEGURIDAD..................................................................................... 55

ANEXO A: .......................................................................................................................................... 56 FORMULARIOS DE EVALUCIÓN DE LA APLICACIÓN DE SOFTWARE. ............ 56

- 5 -

Rev: 05/04-02-2008


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.

- 6 -

Rev: 05/04-02-2008


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.

- 7 -

Rev: 05/04-02-2008


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 2 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."

- 8 -

Rev: 05/04-02-2008


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.

- 9 -

Rev: 05/04-02-2008


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.

- 10 -

Rev: 05/04-02-2008


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".

- 11 -

Rev: 05/04-02-2008


1.6 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.

- 12 -

Rev: 05/04-02-2008


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.

- 13 -

Rev: 05/04-02-2008


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.

- 14 -

Rev: 05/04-02-2008


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.

- 15 -

Rev: 05/04-02-2008


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 o método que particularmente observa alguien en sus operaciones. 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

- 16 -

Rev: 05/04-02-2008


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.

- 17 -

Rev: 05/04-02-2008


1.7 Acrónimos AAC Autoridad Administrativa Competente (CRT del INDECOPI) CC Common Criteria CEN Comité Europeo de Normalización CP Políticas de Certificación CPS Declaración de Prácticas de Certificación de una EC CRL o LCR Certificate Revocation List (Lista de Certificados Revocados) CRT Comisión de Reglamentos Técnicos y Comerciales CWA CEN Workshop Agreements EC Entidad de Certificación ECEP Entidad de Certificación para el Estado Peruano ECERNEP Entidad de Certificación Nacional para el Estado Peruano ER Entidad de Registro o Verificación EREP Entidad de Registro para el Estado Peruano ETSI European Telecommunications Standards Institute FBCA Federal Bridge Certification Authority FIPS Federal Information Processing Standards IEC International Electrotechnical Commission IETF Internet Engineering Task Force IOFE Infraestructura Oficial de Firma Electrónica ISO International Organization for Standardization NTP Norma Técnica Peruana OCSP Online Certificate Status Protocol

(Protocolo del estado en línea del certificado) OID Identificador de Objeto PKI Public Key Infrastructure (Infraestructura de Clave Pública) PSC Prestador de Servicios de Certificación Digital Prestador de Servicios de Criptográficos RFC Request for Comment RPS Declaración de Prácticas de Registro o Verificación de una ER SHA Secure Hash Algorithm SVA Prestador de Servicios de Valor Añadido

(por ejemplo TimeStamping) TSL Lista de Estado de Servicio de Confianza VAPS Declaración de Prácticas de Valor Añadido

- 18 -

Rev: 05/04-02-2008


1.8 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.

- 19 -

Rev: 05/04-02-2008


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.

- 20 -

Rev: 05/04-02-2008


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:

- 21 -

Rev: 05/04-02-2008


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 Métodos de Clave

Pública

Autenticación 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.

- 22 -

Rev: 05/04-02-2008


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.

- 23 -

Rev: 05/04-02-2008


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 Suscriptor Tercero que Confía

(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.

- 24 -

Rev: 05/04-02-2008


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.

- 25 -

Rev: 05/04-02-2008


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.

- 26 -

Rev: 05/04-02-2008


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.

- 27 -

Rev: 05/04-02-2008


• 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.

- 28 -

Rev: 05/04-02-2008


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.

- 29 -

Rev: 05/04-02-2008


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 Clave Privada Clave Pública y Certificado

Firma Digital (Autenticación, integridad, no repudio)

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.

Considerar el volver a cifrar con otra clave si el periodo de almacenamiento excede el tiempo de vida de la clave.

Destrucción; cese del uso.

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.

- 30 -

Rev: 05/04-02-2008


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.

- 31 -

Rev: 05/04-02-2008


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 e-Commerce.

[TSL ETSI TS102.231 v2.0] Electronic Signatures and Infraestructures (ESI); Provision of Harmonized Trust service Provider Satus Information.

[ISO/IEC 15408] International Standard (ISO/IEC 15408) for Computer Security: Common Criteria

- 32 -

Rev: 05/04-02-2008


[RFC 3628] On Policy Requirements for Time-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.

- 33 -

Rev: 05/04-02-2008


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).



- 34 -

Rev: 05/04-02-2008


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: • Verificación de la

identidad empleando la base de datos del RENIEC

ER: • Verificación de la

identidad empleando el sistema de identificación biométrica AFIS del RENIEC

ER: • ISO 9001:2000 • Verificación de la

identidad empleando el sistema de identificación biométrica AFIS del RENIEC

EC: • 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: • 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 27001 • Cumplimiento del

estándar WebTrust for Certification Authorities y obtención del sello de Webtrust, a partir del año 2011

SVA: • Sin certificación; sólo


SVA: • Certificación de

acuerdo al Decreto Legislativo Nº 681, ISO 9001:2000 o ISO 27001

SVA: • Certificación de

acuerdo al Decreto Legislativo Nº 681, ISO 9001:2000 o ISO 27001

Certificaciones de seguridad o calidad del Prestador de Servicios de Certificación Digital – PSC

SW: • Sin certificación; sólo


SW: • ISO 9001:2000, CMMI

nivel 2 (mínimo) u otro equivalente que el INDECOPI determine

SW: • ISO 9001:2000 o

CMMI nivel 3 (mínimo) u otro equivalente que el INDECOPI determine

30 Los detalles de este requisito serán publicados en la siguiente versión de la Guía de Acreditación.

- 35 -

Rev: 05/04-02-2008


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.

- 36 -

Rev: 05/04-02-2008


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.

- 37 -

Rev: 05/04-02-2008


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.

- 38 -

Rev: 05/04-02-2008


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.

- 39 -

Rev: 05/04-02-2008


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.

- 40 -

Rev: 05/04-02-2008


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.

- 41 -

Rev: 05/04-02-2008


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.

- 42 -

Rev: 05/04-02-2008


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.

- 43 -

Rev: 05/04-02-2008


En el caso de los procesos de firma, opcionalmente, se puede: e. Incorporar la razón por la que se firma el documento. f. Permitir la declaración de la ubicación física del firmante. g. Incorporar un comentario (campo adicional). h. Incorporar la rúbrica digitalizada de la firma manuscrita. i. 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.

- 44 -

Rev: 05/04-02-2008


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:

- 45 -

Rev: 05/04-02-2008


• 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.

- 46 -

Rev: 05/04-02-2008


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.

- 47 -

Rev: 05/04-02-2008


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:

- 48 -

Rev: 05/04-02-2008


• 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.

- 49 -

Rev: 05/04-02-2008


5.0 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 DEFINICIÓN Demostració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 componentes de la aplicación, la documentación, etc.

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.

- 50 -

Rev: 05/04-02-2008


Tabla 5. Verificación de los Requerimientos.

Sección Acercamiento de la Verificación 4.2.1.1 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.

- 51 -

Rev: 05/04-02-2008


Sección Acercamiento de la Verificación 4.2.4.3.2 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.


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.

- 52 -

Rev: 05/04-02-2008


Sección Acercamiento de la Verificación 4.2.4.3.2 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 Time-Stamp Protocol (TSP) RFC 3161.


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.

- 53 -

Rev: 05/04-02-2008


Sección Acercamiento de la Verificación 0 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) 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.

b) El SID debe almacenar/archivar los contenidos de las transacciones (mensajes y archivos) enviados a su sistema

c) Los documentos electrónicos, si fuera el caso, serán creados con valor legal de acuerdo al D.L 681.

d) 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.

e) El SID debe proveer un medio de conexión de transacciones seguras (canal SSL) y soporte para certificados digitales.

f) 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.

- 54 -

Rev: 05/04-02-2008


Sección 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.


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.

- 55 -

Rev: 05/04-02-2008


Sección Acercamiento de la Verificación 0 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.


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 s-mime y los documentos electrónicos adjuntos (attachment) deberán estar firmados digitalmente de manera individual.


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.

- 56 -

Rev: 05/04-02-2008


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.

- 57 -

Rev: 05/04-02-2008


Formulario 1

RESULTADO

- Claves del suscriptor- Generación del par de claves

- Uso de la TSL

- Recuperación de Información

- 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 del Estado del Certificado (CRL)- Verificación del Estado del Certificado (Respondedor OCSP)-Opcional

- Certificados y CRLs - Recuperación de las claves de cifrado (opcional)

- Desarrollo y procesamiento de la ruta

- Verificación del Estado mediante la lista TSL

- Comprobación de funcionalidades

- Comprobación de funcionalidades

- Aplicación firmada empleando un certificado de firma de código- Configuración de la aplicación

- 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

- Manuales de usuario y administrador - Configuración para la interoperabilidad- Responsabilidades como usuarios de la Infraestructura de Clave Pública (PKI)

CRITERIO

Resultados de la prueba de interoperabilidad de la APLICACIÓN

VERIFICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN

REVISIÓN DEL ESTADO DEL CERTIFICADO

GENERACIÓN DE PAR DE CLAVES (para aplicaciones que generen claves)

USO DE LA TSL (en la medida que se encuentre implementada por la AAC)

IMPORTACIÓN Y EXPORTACIÓN DE CLAVES Y CERTIFICADOS

RECUPERACIÓN DE INFORMACIÓN

CONFIGURACIÓN DE LA APLICACIÓN

DOCUMENTACIÓN DE LA APLICACIÓN

RECUPERACIÓN DE CERTIFICADOS Y LISTAS DE CERTIFICADOS REVOCADOS

DESARROLLO Y PROCESAMIENTO DE LA RUTA

SISTEMA DE INTERMEDIACIÓN DIGITAL SID

FIRMA DIGITAL

VERIFICACIÓN DE LA FIRMA DIGITAL

VERIFICACIÓN DEL ESTADO DEL PROVEEDOR DE SERVICIOS DE CERTIFICACIÓN

- 58 -

Rev: 05/04-02-2008


Formulario 2

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

FORMULARIO DE RECOLECCIÓN DE DATOS - INFORMACIÓN DETALLADA PARA LA PRUEBA DE LA APLICACIÓN

Diagrama de Prueba de red:

Archivos usados:

Passwords Usados:

Comentarios/Notas:

Certificados de firma de código usados (Incluye contraseñas de certificado):

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:

- 59 -

Rev: 05/04-02-2008


Formulario 3 (Opcional)

Nombre de la Aplicación:______________________ Evaluadores (Recolectores de Datos/Operadores): __________________ __________________

Ubicación: ____________________________________ Fecha:_______________________________

DATOS DE PRUEBA ESPECÍFICOS

EVENTO

Resultados/Notas:

Resultado: Aprobado FallidoClaves 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.

RESULTADOSACCIÓN DEL RECOLECTOR DE DATOSEVENTO DE PRUEBA

Archivos usado (si aplica):

Anomalías:

FORMULARIO DE RECOLECCIÓN DE DATOS – GENERACIÓN DEL PAR DE CLAVES

Software usado para la prueba:

Equipo usado para la prueba:

Certificados usados (si aplica):

- 60 -

Rev: 05/04-02-2008


Formulario 4 (Para aplicaciones con generación de claves)

Nombre de la Aplicación:______________________ Evaluadores (Recolectores de Datos/Operadores): __________________ __________________

Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

FORMULARIO DE RECOLECCIÓN DE DATOS – GENERACIÓN DEL PAR DE CLAVES




Resultados/Notas:

Resultado: Aprobado FallidoGeneración del Par de Claves: Generación de pares de claves usando un algoritmo estándar reconocido por la AAC para la acreditación.

RESULTADOSACCIÓN DEL RECOLECTOR DE DATOS


Anomalías:

EVENTO DE PRUEBA

- 61 -

Rev: 05/04-02-2008


Formulario 5 (En la medida que la TSL esté implementada por la AAC)

Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________

Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

FORMULARIO DE RECOLECCIÓN DE DATOS – USO DE LA TSL




Resultados/Notas:

Resultado: Aprobado FallidoUso de la TSL: Procesamiento de los proveedores de servicios acreditados en la lista TSL según estándar ETSI TS 102 231.



Anomalías:

EVENTO DE PRUEBA

- 62 -

Rev: 05/04-02-2008


Formulario 6 (Opcional para certificados de cifrado)

Nombre de la Aplicación:______________________ Evaluador(es) (Recolectores de Datos/Operadores): _________________ _________________

Ubicación: ____________________________________ Fecha:_______________________________


EVENTO


Archivos usados (si aplica):

Anomalías:

EVENTO DE PRUEBA

FORMULARIO DE RECOLECCIÓN DE DATOS – RECUPERACIÓN DE INFORMACIÓN




Resultados/Notas:

Resultado: Aprobado FallidoRecuperación de Información: Uso de una clave privada recuperada del sistema de manejo de recuperación de claves de la IOFE.

- 63 -

Rev: 05/04-02-2008


Formulario 7 (Para aplicaciones propietarias que no utilizan la funcionalidad del sistema operativo)


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

FORMULARIO DE RECOLECCIÓN DE DATOS – IMPORTACIÓN Y EXPORTACIÓN DE CERTIFICADOS




Resultados/Notas:

Resultado: Aprobado FallidoImportación de Claves y Certificados: Importación de claves asociadas con certificados estandarizados para individuos.



Anomalías:

EVENTO DE PRUEBA

- 64 -

Rev: 05/04-02-2008




Ubicación: ____________________________________ Fecha:_______________________________


EVENTO





Resultados/Notas:

Resultado: Aprobado FallidoTipos de Certificados: Importación de por lo menos un conjunto de claves y certificados para cada tipo de certificado que soporta.



Anomalías:

EVENTO DE PRUEBA

- 65 -

Rev: 05/04-02-2008




Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

Resultados/Notas:

Resultado: Aprobado FallidoExportación de Claves y Certificados



Anomalías:

EVENTO DE PRUEBA





- 66 -

Rev: 05/04-02-2008


Formulario 10 (Para SID y aplicaciones con generación de certificados)


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN




Resultados/Notas:

Resultado: Aprobado FallidoVerificación de los Protocolos de Comunicación: Comunicación con la IOFE usando un protocolo LDAP, HTTP o HTTPS.



Anomalías:

EVENTO DE PRUEBA

- 67 -

Rev: 05/04-02-2008


Formulario 11


Ubicación: ____________________________________ Fecha:_______________________________


RESULTADO ACTUAL

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.

Resultados/Notas:

Resultado: Aprobado Fallido


Anomalías:

COMENTARIOSAPROBADO

OFALLIDO

PRUEBAS DE NIVEL 1RL.02.01 FRACASO

DESIGNADORRESULTADO DE

VALIDACIÓNESPERADO

RL.03.01RL.05.01RL.06.01RL.07.01

FRACASOFRACASOFRACASOFRACASO

RL.08.01 FRACASORL.09.01 FRACASO

PRUEBAS DE NIVEL 2RL.03.02 FRACASORL.03.03 ÉXITORL.05.02 FRACASORL.06.02 FRACASORL.07.02 FRACASORL.07.03 ÉXITO

- 68 -

Rev: 05/04-02-2008


Formulario 12 (Opcional)


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

Resultados/Notas:

Resultado: Aprobado FallidoVerificación del Estado del Certificado (Respondedor OSC): Capacidad de recuperar una respuesta OSC.



Anomalías:

EVENTO DE PRUEBA

FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DEL ESTADO DEL CERTIFICADO




- 69 -

Rev: 05/04-02-2008




Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

Resultados/Notas:



Anomalías:

EVENTO DE PRUEBA

FORMULARIO DE RECOLECCIÓN DE DATOS – DESARROLLO Y PROCESAMIENTO DE RUTA




Resultado: Aprobado FallidoDesarrollo y Procesamiento de Ruta: Capacidad de desarrollar la ruta del certificado y su procesamiento, así como el procesamiento de la lista TSL.

- 70 -

Rev: 05/04-02-2008




Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

Resultados/Notas:

Resultado: Aprobado FallidoVerificación del Estado del proveedor de servicios de certificación mediante la lista TSL



Anomalías:

EVENTO DE PRUEBA

FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DEL ESTADO DEL PROVEEDOR DE SERVICIOS DE CERTIFICACIÓN




- 71 -

Rev: 05/04-02-2008


Formulario 15


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

FORMULARIO DE RECOLECCIÓN DE DATOS – FIRMA DIGITAL




Resultados/Notas:

Resultado: Aprobado FallidoComprobación de funcionalidades: Cosign, normas de la IOFE y estándares. Realización de verificaciones antes de la firma.



Anomalías:

EVENTO DE PRUEBA

- 72 -

Rev: 05/04-02-2008


Formulario 16


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

1

Notas:

2

Notas:

3

Notas:

Garantizar el no repudio e integridad del documento firmado

Visualización de extensiones

Garantizar que se utiliza el estándar Time Stamp RFC 3161 para establecer la fecha y hora cierta

FORMULARIO DE RECOLECCIÓN DE DATOS – VERIFICACIÓN DE LA FIRMA DIGITAL




Resultados/Notas:

Resultado: Aprobado FallidoComprobació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.



Anomalías:

EVENTO DE PRUEBA

- 73 -

Rev: 05/04-02-2008


Formulario 17

Nombre de la Aplicación:______________________________ Evaluador(es) (Recolectores de Datos/Operadores): __________________ __________________

Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

2

Garantizar la autoría e integridad de la (APLICACIÓN): uso de un certificado de firma de código.

Notas:

Asegurar que la (APLICACIÓN) es capaz de llegar a ser configurada para operar con los puntos de confianza de la IOFE.

Notas:

7

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:

5

Asegurar que la (APLICACIÓN) está configurada para una operación segura en su medio.

Notas:

4

Asegurar que la (APLICACIÓN) ha identificado todas las condiciones necesarias y dependencias para una ejecución segura de sus funciones.

Notas:

1

3

Resultados/Notas:

Notas:

Asegurar que la (APLICACIÓN) está configurada para operar en el marco de la IOFE

Notas:

Asegurar que la (APLICACIÓN) ha identificado las condiciones de operación requeridas de su entorno de operación.



Anomalías:

EVENTO DE PRUEBA

FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - CONFIGURACIÓN DE LA APLICACIÓN




Resultado: Aprobado FallidoConfiguración de la Aplicación: Uso de la aplicación en el marco de la IOFE.

- 74 -

Rev: 05/04-02-2008


Formulario 18


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO

3

Notas:

Notas:

Notas:

4

2

FORMULARIO DE RECOLECCIÓN DE DATOS – SISTEMA DE INTERMEDIACIÓN DIGITAL SID




Resultados/Notas:

Resultado: Aprobado FallidoComprobación de funcionalidades: Trabajo on line, seguridad, cumplimiento del DL 681.



Anomalías:

EVENTO DE PRUEBA

1

- 75 -

Rev: 05/04-02-2008


Formulario 19


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO





Resultados/Notas:

Resultado: Aprobado FallidoModos de autenticación: Comprobación de los dos mecanismos previstos.



Anomalías:

EVENTO DE PRUEBA

Notas

2

1

Notas

Doble Factor de Autenticación

Triple factor de Autenticación

- 76 -

Rev: 05/04-02-2008


Formulario 20


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO



Anomalías:

EVENTO DE PRUEBA





Resultados/Notas:

Resultado: Aprobado FallidoModos de generación de documentos firmados digitalmente: Comprobación de los dos mecanismos previstos.

Notas:

1

2

Notas:

Documento de cualquier extensión firmado y cargado al servidor del Sistema de Intermediación

Generación de correo electrónico seguro, formato s-mime

- 77 -

Rev: 05/04-02-2008


Formulario 21


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO





Resultados/Notas:

Resultado: Aprobado FallidoModos de generación de acuses de recibo: Comprobación de los dos mecanismos previstos.



Anomalías:

EVENTO DE PRUEBA

2

Notas:

Notas:

1

Domicilio electrónico

Correo electrónico

- 78 -

Rev: 05/04-02-2008


Formulario 22


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO



Anomalías:

EVENTO DE PRUEBA





Resultados/Notas:

Resultado: Aprobado FallidoModos de Verificación de los documentos firmados digitalmente: Comprobación de los dos mecanismos previstos.

Notas:

Notas:

Verificación On-line

Verificación Off-line

- 79 -

Rev: 05/04-02-2008


Formulario 23


Ubicación: ____________________________________ Fecha:_______________________________


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

1

2

3

4

5

6

FORMULARIO DE RECOLECCIÓN DE INFORMACIÓN - DOCUMENTACIÓN DE LA APLICACIÓN




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.

Las instrucciones contemplan la configuración de la aplicación para acceso SSL a la IOFE, si fuera necesario.

Las instrucciones contemplan políticas de seguridad en el marco de la IOFE.

Las instrucciones contemplan el empleo del TSL.

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.

Las instrucciones contemplan la interoperabilidad con certificados x509v3 de diversos proveedores acreditados o no.

Resultados/Notas:

Resultado: Aprobado FallidoManuales 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.



Anomalías:

EVENTO DE PRUEBA

- 80 -

Rev: 05/04-02-2008


Formulario 24


Ubicación: ____________________________________ Fecha:_______________________________


EVENTO



Anomalías:

EVENTO DE PRUEBA





Resultados/Notas:

Resultado: Aprobado FallidoConfiguración para la Interoperabilidad: Instrucciones de configuración para interoperar con la IOFE.

2

3

Notas:

Notas:

Notas:

1

- 81 -

Rev: 05/04-02-2008


Formulario 25


Ubicación: ____________________________________ Fecha:_______________________________


Resultados/Notas:


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

1

2





Los documentos de la APLICACIÓN contienen instrucciones sobre medidas técnicas o procedimentales para proteger la clave privada contra compromiso y uso inapropiado.

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).

Resultado: Aprobado FallidoResponsabilidades con usuarios de la PKI: Instrucción a usuarios y administradores.



Anomalías:

EVENTO DE PRUEBA

- 82 -

Rev: 05/04-02-2008


Formulario 26


Ubicación: ____________________________________ Fecha:_______________________________


Resultados/Notas:


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.

Resultado: Aprobado FallidoCumplimiento de los requerimientos de Usabilidad.


Anomalías:





- 83 -

Rev: 05/04-02-2008


(Continuación)

EVENTO

1

2

3

4

5

6

7

8

9

10

11

12

13

14

RESULTADOSACCIÓN DEL RECOLECTOR DE DATOSEVENTO DE PRUEBA

Instalación y Configuración:Proceso sencillo de instalación y configuración, tal que ejecutarlos de manera exitosa desde la primera vez.

Idioma:Toda la información y los ejemplos son presentados en español.

Requerimiento Técnico:Posibilidad de instalación y operación con hardware y software existente.

Requerimiento Técnico:Posibilidad de ser soportados en múltiples sistemas operativos.

Requerimiento Técnico:Informe al usuario de los programas adicionales requeridos para la instalación.

Instalación y Configuración:Facilidad de adapción de la configuración a necesidades individuales.

Instalación y Configuración:Cuenta con una guía de instalación y configuración.

Soporte Técnico:Disponibilidad de dirección electrónica o número telefónico de contacto y disponibilidad de horario.

Uso de la aplicación:Disponibilidad de mensajes de ayuda durante una operación.

Uso de la aplicación:Presentación de mensajes de peligro si se está ejecutando una operación sensible respecto de la seguridad.


Uso de la aplicación:Características de seguridad comprensibles para los usuarios.

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.

Normatividad:Presentación de mensajes referidos a las consecuencias legales vinculadas.

- 84 -

Rev: 05/04-02-2008



Nombre de la Aplicación: ______________________ Versión: __________

Evaluador(es) (Recolectores de Información/Operador ____________________ ____________________

Lugar(es) de la prueba: ____________________ ____________________

Información del Reporte: Reporte Completado por: ______________________________ Fecha : __ / __ / __ Hora: _________

REPORTE VERIFICACIÓN DE CONFORMIDAD DEL EMPLEO DE TSL ETSI TS102.231 FECHA ___ / ___ / ___

- 85 -

Rev: 05/04-02-2008


Formulario 28

Nombre de la Aplicación: ______________________ Versión: __________

Evaluador(es) (Recolectores de Información/Operador ____________________ ____________________

Lugar(es) de la prueba: ____________________ ____________________

Información del Reporte: Reporte Completado por: ______________________________ Fecha : __ / __ / __ Hora: _________

Resultados/Notas:

Anomalías:

REPORTE DIARIO DE ESTADO DE PRUEBA FECHA ___ / ___ / ___

Pruebas completadas el día de hoy:

Pruebas esperadas para ser completadas el día de mañana:

- 86 -

Rev: 05/04-02-2008


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

- 87 -

Rev: 05/04-02-2008



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

- 88 -

Rev: 05/04-02-2008



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

- 89 -

Rev: 05/04-02-2008



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

guía de acreditación de aplicaciones de software · 4.2.1 manejo de claves ... los documentos...

Documents