anÁlisis de estÁndares internacionales para la...
TRANSCRIPT
UNIVERSIDAD DE COSTA RICA SISTEMA DE ESTUDIOS DE POSGRADO
ANÁLISIS DE ESTÁNDARES INTERNACIONALES PARA LA CERTIFICACIÓN
DE AUTORIDADES CERTIFICADORAS Y SU APLICABILIDAD EN EL SISTEMA NACIONAL DE CERTIFICACIÓN DIGITAL DE COSTA RICA
Trabajo final de Investigación aplicada sometido a la consideración de la Comisión del Programa de Estudios de Posgrado en Computación e Informática para optar al grado y título de Maestría Profesional en
Computación e Informática
Rodrigo A. Bartels
Ciudad Universitaria Rodrigo Facio, Costa Rica
2016
ii
A mi esposa Raquel,
porque sin importar los logros que alcance, el más grande de todos siempre será
el estar cada día a tu lado.
R.
iii
Agradecimientos
La realización de este trabajo de investigación no hubiera sido posible sin la
colaboración de múltiples entidades y personas:
§ La Dirección de Certificadores de Firma Digital, en especial a su director Alexander
Barquero por el apoyo y confianza durante la realización de este proyecto.
§ La división de Seguridad Informática del Banco Central de Costa Rica por su iniciativa
para mejorar el Sistema Nacional de Certificación Digital y su apoyo en reuniones,
eventos y el compartir todo el conocimiento adquirido durante 10 años de
administración de la CA-SINPE.
§ El Centro de Investigaciones en Tecnologías de Información y Comunicación (CITIC)
por su apoyo durante la realización de este proyecto.
§ La Escuela de Ciencias de la Computación e Informática de la Universidad de Costa
Rica y en particular al Posgrado en Computación e Informática por fomentar el trabajo
de investigación y el apoyo al mejoramiento de la realidad nacional mediante este tipo
de proyectos de investigación.
El sustentante quisiera agradecer de forma especial al Dr. Ricardo Villalón Fonseca y a
la Dra. Gabriela Marín Raventós por su apoyo, guía, motivación, dedicación y paciencia en
la ejecución del proyecto de investigación y en particular en el desarrollo de este Trabajo de
Investigación Aplicada.
Finalmente, un agradecimiento a la Dra. Gabriela Barrantes, a la Dra. Elzbieta
Malinowski y al M.Sc Edgar Casasola por sus enseñanzas a lo largo de todos estos años de
estudio en la ECCI.
iv
Este trabajo final de investigación aplicada fue aceptado por la Comisión del Programa de Estudios de Posgrado en Computación e Informática de la
Universidad de Costa Rica, como requisito parcial para optar al grado y título de Maestría Profesional en Computación e Informática.
________________________________________ Dr. Marcelo Jenkins Coronas Representante del Decano
Sistema de Estudios de Posgrado
________________________________________ Dr. Ricardo Villalón Fonseca
Profesor Guía
________________________________________ Dra. Gabriela Marín Raventós
Representante Programa de Posgrado en Computación e Informática
______________________________________________ Rodrigo A. Bartels
Sustentante
v
Tabla de Contenidos
Agradecimientos .................................................................................................................. iii
Tabla de Contenidos ............................................................................................................ v
Resumen ............................................................................................................................... ix
Índice de Tablas ................................................................................................................... x
Índice de Figuras ................................................................................................................. xi
Índice de abreviaturas ....................................................................................................... xii
1. Introducción ................................................................................................................. 1
1.1. Contexto .................................................................................................................... 2
1.2. Motivación ................................................................................................................ 4
1.3. Objetivos y metodología .......................................................................................... 6
1.4. Alcance ...................................................................................................................... 8
1.5. Organización del documento .................................................................................. 8
2. Marco teórico ............................................................................................................... 9
2.1. Conceptos Básicos de Seguridad ............................................................................ 9
2.1.1. Objetivos de Seguridad ..................................................................................... 11
2.1.2. Políticas y Mecanismos ...................................................................................... 12
2.2. Conceptos Básicos de Criptografía ....................................................................... 13
2.2.1. Sistemas Criptográficos Clásicos ...................................................................... 15
2.2.2. Criptografía de Llave Pública ........................................................................... 17
2.2.3. Firmas Digitales ................................................................................................. 18
2.3. Certificados Digitales ............................................................................................. 20
2.3.1. Estado de un Certificado ................................................................................... 24
2.4. Infraestructura de Llave Pública ......................................................................... 27
2.4.1. Autoridad Certificadora .................................................................................... 28
2.4.2. Autoridades Certificadoras Subordinadas (Sub-CA) .................................... 33
2.4.3. Autoridad de Registro ....................................................................................... 34
2.4.4. Repositorio y Archivo ........................................................................................ 35
vi
2.4.5. Entidades Finales: Usuarios y Dispositivos ..................................................... 36
3. Estándares internacionales para PKI ...................................................................... 37
3.1. Metodología ............................................................................................................ 38
3.2. Estándares Seleccionados ...................................................................................... 40
3.3. ISO-21188: Public key infrastructure for financial services .............................. 46
3.3.1. Estructura ........................................................................................................... 48
3.3.2. Proceso de Evaluación ....................................................................................... 50
3.4. Trust Service Principles and Criteria for Certification Authorities ................. 53
3.4.1. Relación entre ISO-21188 y Webtrust ............................................................. 53
3.4.2. Estructura ........................................................................................................... 55
3.4.3. Proceso de evaluación y auditoría .................................................................... 57
3.5. ETSI TS 102 042 .................................................................................................... 57
3.6. Resumen .................................................................................................................. 62
4. Identificación de requisitos nacionales .................................................................... 64
4.1. Problemática existente. .......................................................................................... 64
4.2. Identificación de los requisitos .............................................................................. 66
4.2.1. Ley 8454 y Reglamento. ..................................................................................... 67
4.2.2. Política de Certificados ...................................................................................... 70
4.3. Requisitos identificados ......................................................................................... 73
5. Aplicabilidad de los Estándares ................................................................................ 79
5.1. Principios de Evaluación ....................................................................................... 79
5.2. Metodología ............................................................................................................ 80
5.2.1. Escenarios definidos .......................................................................................... 81
5.3. ETSI ........................................................................................................................ 83
5.4. ISO-21188 ............................................................................................................... 84
5.5. Webtrust ................................................................................................................. 88
6. Conclusiones ............................................................................................................... 96
6.1. Impacto ................................................................................................................... 98
6.2. Trabajo Futuro....................................................................................................... 99
vii
6.3. Recomendaciones ................................................................................................. 101
6.4. Resultados Adicionales ........................................................................................ 103
6.4.1. Curso de PKI .................................................................................................... 103
6.4.2. Autoridad de Registro de OID ........................................................................ 104
6.4.3. Política de Certificado para la Universidad de Costa Rica .......................... 106
7. Bibliografía ............................................................................................................... 108
Apéndice A: Programa de Curso de PKI ...................................................................... 112
Apéndice B: Requisitos para una CA en Costa Rica .................................................... 117B.1 Política de Certificados ................................................................................................ 118B.2 Requisitos Legales ........................................................................................................ 119B.3 Requisitos Financieros ................................................................................................. 120B.4 Personal de la CA ......................................................................................................... 120B.5 Roles y Funciones ......................................................................................................... 124B.6 Dispositivos Criptográficos .......................................................................................... 126B.7 Generación Llaves ........................................................................................................ 129B.8 Administración Llave de la CA ................................................................................... 131B.9 Publicación de Información ......................................................................................... 135B.10 Autoridades de Registro .............................................................................................. 138B.11 Proceso de Registro ...................................................................................................... 138B.12 Dispositivos Criptográficos Usuario Final ................................................................. 140B.13 Emisión de Certificados ............................................................................................... 143B.14 Uso del Certificado ....................................................................................................... 147B.15 Validación de Certificados ........................................................................................... 148B.16 Revocación de Certificados .......................................................................................... 152B.17 Suspensión de Certificados .......................................................................................... 153B.18 Infraestructura de Red ................................................................................................ 155B.19 Administración de Equipo Computacional ................................................................ 157B.20 Desarrollo de Software ................................................................................................. 161B.21 Documentación ............................................................................................................. 162B.22 Gestión de Operaciones ................................................................................................ 164B.23 Autenticación ................................................................................................................ 164B.24 Seguridad de la Información ....................................................................................... 165B.25 Seguridad Física y Ambiental ..................................................................................... 168
viii
B.26 Acceso a las Instalaciones ............................................................................................ 171B.27 Gestión de la continuidad del negocio ........................................................................ 172B.28 Bitácoras y Registros de Auditorías ............................................................................ 176B.29 Procesos de Auditoría .................................................................................................. 184B.30 Conservación de Registros ........................................................................................... 186B.31 Terminación de una CA ............................................................................................... 186B.32 Certificaciones & Estándares ...................................................................................... 187B.33 Formato Certificados ................................................................................................... 188B.34 Respaldos de Información ........................................................................................... 190
ix
Resumen
En abril del 2014, con el anuncio de la directriz gubernamental 067-MICITT-H-MEIC [1] el Poder Ejecutivo de la República de Costa Rica facultó al ciudadano costarricense a exigir la prestación de servicios por medio de la firma digital en todas las entidades de Gobierno. Con este proceso en marcha, los diversos actores involucrados en la implementación de la firma digital en Costa Rica iniciaron un proceso de auto evaluación con el objetivo de mejorar y preparar la Infraestructura de Firma Digital para un esperado uso masivo a nivel nacional.
El objetivo principal de este proyecto de investigación fue analizar estándares internacionales para la certificación de Autoridades Certificadoras (CA) en infraestructuras de llave pública y evaluar su aplicabilidad dentro del Sistema Nacional de Certificación Digital (SNCD). Los estándares considerados fueron:
§ ISO 21188:2006 Public key infrastructure for financial . § Trust Service Principles and Criteria for Certification Authorities Version 2.0.
§ ETSI TS 102 042 V2.3.1: Electronic Signatures and Infrastructures (ESI): Policy requirements for certification authorities issuing public key certificates.
Durante el proceso de evaluación el obstáculo más importante para la evaluación de la aplicabilidad de cada estándar fue que no hay una lista concisa, clara y disponible de todos los requisitos que una CA debe implementar para operar en Costa Rica. Para iniciar el proceso de identificación de los requisitos se realizó un proceso de revisión de las leyes y reglamentos vigentes y de las políticas vigentes de la Dirección de Certificadores de Firma Digital (DCFD). También se realizaron grupos de trabajo con la DCFD y organizaciones vinculadas con el SNCD, como el Banco Central y el Ente Costarricense de Acreditación (ECA). En total se identificaron 593 requisitos, la mayoría de ellos pertenecen a la Política de Certificados o al ISO-21188. Con los requisitos identificados se creó un conjunto de los requisitos que debe cumplir una Autoridad Certificadora en Costa Rica. Esto se realizó comparando los distintos requisitos de cada documento y eliminando los requisitos duplicados o semánticamente iguales. En total, se obtuvieron 416 requisitos únicos que una CA debe cumplir. Finalmente, se analizó la aplicabilidad de los estándares llegando a la conclusión de que un proceso de auditoría con la norma ISO-21188 o el estándar de Webtrust se puede realizar para las Autoridades Certificadoras del SNCD porque ambos implican la revisión de todos los documentos que contienen requisitos que actualmente son necesarios en Costa Rica. En el caso del ETSI TS 102, durante el proceso de investigación se descubrió que los estándares europeos están en un proceso de transición como consecuencia de la aprobación de una nueva legislación en el año 2014 (eIDAS). Por esta razón, la aplicación del estándar europeo no fue analizada. Este trabajo de investigación se desarrolló como parte del proyecto de investigación Desarrollo de esquemas para certificar autoridades y aplicaciones de software en el Sistema Nacional de Certificación Digital (SNCD), inscrito en la Universidad de Costa Rica (UCR) y desarrollado en conjunto por la ECCI, el CITIC, el MICITT y el Banco Central de Costa Rica (BCCR).
x
Índice de Tablas
Tabla 1. Modelo del idioma español. ................................................................................... 14
Tabla 2. Estructura típica de un certificado digital. ............................................................. 22
Tabla 3. Descripción de extensiones de certificados típicamente utilizadas. ...................... 25
Tabla 4. Estándares requeridos en los países de América Latina para la implementación de
Autoridades Certificadoras. ................................................................................................. 42
Tabla 5. Estándares solicitados por sistemas operativos para incluir la llave pública de una
CA en su repositorio de certificados. ................................................................................... 43
Tabla 6. Estándares requeridos por exploradores web y Adobe. ......................................... 45
Tabla 7. Escenarios de aplicación de certificados en un ambiente cerrado. ........................ 49
Tabla 8. Estructura de los objetivos de control especificados en el ISO 21188. ................. 51
Tabla 9. Estructura de los contenidos de Webtrust. ............................................................. 58
Tabla 10. Requisitos especificados por el Reglamento a la Ley 8454. ................................ 68
Tabla 11. Requisitos identificados en cada uno de los documentos analizados. ................. 74
Tabla 12. Lista de categorías de requisitos definidas .......................................................... 75
Tabla 13. Requisitos definidos en la Política de Certificados faltantes en el ISO-21188. .. 85
Tabla 14. Objetivos de control que son requeridos por Webtrust 2.0 y que no están presentes
en la norma ISO-21188. ....................................................................................................... 91
Tabla 15. Objetivos de control que presentan requisitos adicionales en Webtrust 2.0 con
respecto a la norma ISO-21188. ........................................................................................... 92
xi
Índice de Figuras
Figura 1. Metodología utilizada para el desarrollo de la investigación. ................................ 7
Figura 2. Algoritmo de Cifrado Simétrico ........................................................................... 15
Figura 3. Proceso de verificación de una firma digital. ....................................................... 19
Figura 4. Contenido del Certificado Digital de la CA Raíz del Sistema Nacional de
Certificación Digital de Costa Rica. .................................................................................... 26
Figura 5. Infraestructura típica de llave pública. ................................................................. 29
Figura 6. Jerarquía de la Infraestructura de Llave Pública del Sistema Nacional de
Certificación Digital (Elaboración propia). ......................................................................... 34
Figura 7. Metodología utilizada para la selección de estándares. ........................................ 39
Figura 8. Evolución de los estándares para certificación y auditoria de Autoridades
Certificadoras. ...................................................................................................................... 56
Figura 9. Metodología para la identificación de requisitos. ................................................. 67
Figura 10. Referencias existentes entre los documentos analizados. ................................... 74
Figura 11. Proceso de revisión de los requisitos establecidos para una auditoría que inicie
con la norma ISO-21188. ..................................................................................................... 88
Figura 12. Proceso de revisión de los requisitos establecidos para una auditoría que inicie
con WebTrust 2.0 para CA. ................................................................................................. 90
Figura 13. Posible sistema de certificación definido con base en el ISO-17067 para la
certificación de CA del SNCD. .......................................................................................... 101
xii
Índice de abreviaturas
AICPA American Institute of Certified Public Accountants
CA Autoridad Certificadora
CA-SINPE Autoridad Certificadora del Sistema Nacional de Pagos Electrónicos
CICA Canadian Institute of Chartered Accountants
CP Política de Certificado
CPS Certificate Practice Statement
CRL Certificate Revocation List
CSE Communications Security Establishment (Canada)
DCFD Dirección de Certificadores de Firma Digital
DNS Domain Name System
DSA Digital Signature Algorithm
ECA Ente Costarricense de Acreditación
ESI Electronic Signatures and Infrastructures
ETSI European Telecommunications Standards Institute
ETSI TS European Telecommunications Standards Institute Technical Specification
EU European Union
FIPS Federal Information Processing Standard
HTTP Hypertext Transfer Protocol
IEC International Electrotechnical Commission
ISO International Organization for Standardization
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IE Internet Explorer
IT Tecnologías de Información
LDAP Lightweight Directory Access Protocol
MICITT Ministerio de Ciencia, Tecnología y Telecomunicaciones
NIST National Institute of Standards and Technology
xiii
NSS Network Security Services
OCDE Organisation for Economic Co-operation and Development
OCSP Online Certificate Status Protocol
PEM Privacy Enhanced Mail
PCMCIA Personal Computer Memory Card International Association
PKI Public Key Infrastructure
R&D Research & Development
RA Autoridad de Registro
RFC Request for Comments
RSA Algoritmo Rivest-Shamir-Adleman
SNCD Sistema Nacional de Certificación Digital
SINPE Sistema Nacional Pagos Electrónicos
SSL Secure Sockets Layer
TLS Transport Layer Security
URI Uniform Resource Identifier
VPN Virtual Private Network
1
1. Introducción
En abril del 2014, con el anuncio de la directriz gubernamental 067-MICITT-H-MEIC
[1] el Poder Ejecutivo de la República de Costa Rica facultó al ciudadano costarricense a
exigir la prestación de servicios por medio de la firma digital en todas las entidades de
Gobierno. La publicación de esta directriz tuvo varios objetivos [2]:
1. Incrementar la transparencia en el sector público empoderando al ciudadano a tener
acceso a información de carácter público mediante medios electrónicos y gratuitos.
2. Facilitar al ciudadano la utilización de los servicios públicos, realización de
solicitudes, solicitud de constancias, entrega de ofertas, formularios y documentos
válidos legalmente sin tener que acudir a las oficinas de Gobierno.
3. Reducir la cantidad de papel utilizado para trámites gubernamentales con el fin de
contribuir con las metas de carbono neutral del Gobierno de la República para el año
2020.
La publicación de esta directriz conlleva un esfuerzo enorme para las más de 300
entidades públicas que según la directriz tienen hasta diciembre de 2016 para implementar
versiones electrónicas, utilizando la firma digital oficial, como mecanismo de autenticación
y firma, de todos los servicios que brindan actualmente de forma física. En paralelo, el
Gobierno de la República ha emprendido esfuerzos para incrementar la cantidad de
ciudadanos que utiliza la firma digital como un recurso para el manejo de documentos de
forma electrónica, con el fin de que los esfuerzos de implementación en el sector público
sean aprovechados por el mayor número de ciudadanos.
Con estos dos procesos en marcha, los diversos actores involucrados en la
implementación de la firma digital en Costa Rica iniciaron un proceso de auto evaluación
con el objetivo de mejorar y preparar la Infraestructura de Firma Digital para un esperado
2
uso masivo a nivel nacional. Por ejemplo, durante el año 2015 y 2016 se realizó un proceso
de renovación de las llaves privadas de todas las Autoridades Certificadoras aumentando el
largo de las llaves, se aumentó la vida útil de un certificado digital nacional de 2 a 4 años,
se eliminó la restricción de un certificado digital por ciudadano, se empezó a utilizar
algoritmos de la familia de SHA2 en la generación de las llaves de los certificados digitales
y finalmente se inició un proceso de evaluación de los procesos de auditoría y evaluación de
las Autoridades Certificadoras a nivel nacional.
Este trabajo de investigación aplicada se desarrolló como parte de ese esfuerzo de
evaluación de los procesos de auditoría de las Autoridades Certificadoras. Este documento
presenta los resultados obtenidos durante año y medio de trabajo como parte del primer
objetivo planteado por el proyecto de investigación Desarrollo de esquemas para certificar
autoridades y aplicaciones de software en el Sistema Nacional de Certificación Digital
(SNCD), inscrito ante la Vicerrectoría de Investigación de la Universidad de Costa Rica
(UCR) y desarrollado en conjunto por la Escuela de Ciencias de la Computación (ECCI), el
Centro de Investigaciones en Tecnologías de la Información y Comunicación (CITIC),
ambos de la UCR, el Ministerio de Ciencia, Tecnología y Telecomunicaciones (MICITT) y
el Banco Central de Costa Rica (BCCR).
1.1. Contexto
El origen de la certificación digital en Costa Rica se remonta al año 2002, cuando el
Poder Ejecutivo presentó a la Asamblea Legislativa un proyecto con el que buscaba legislar
el uso de la firma digital. El 22 de agosto del 2005 se logró la aprobación de la Ley 8454 [3],
Ley de Certificados, Firmas Digitales y Documentos Electrónicos. Esta ley define el marco
legal para el uso de certificados y firmas digitales como un mecanismo equivalente a la firma
manuscrita, así como su validez y aplicabilidad a documentos electrónicos.
El Sistema Nacional de Certificación Digital es una Infraestructura de Llave Pública
utilizada a nivel nacional para la generación de certificados digitales para los ciudadanos.
3
Este certificado les permite identificarse y firmar documentos electrónicamente de forma
inequívoca y no repudiable de una forma legalmente válida y vinculante. La Ley 8454
también regula a los actores del Sistema Nacional de Certificación Digital y crea la Dirección
de Certificadores de Firma Digital (DCFD), un ente adscrito al Ministerio de Ciencia,
Tecnología y Telecomunicaciones (MICITT), encargado de ser el organismo encargado de
administrar, mantener y asegurar la confianza y seguridad del Sistema. Para esto, la Ley le
permite definir vía reglamento los requisitos que deben cumplir los distintos actores del
Sistema.
En una Infraestructura de Llave Pública participan diversos actores, cada uno con roles
diferentes dentro del proceso para emitir y usar certificados digitales. En el contexto del
SNCD, el MICITT es el dueño de los certificados raíz y es el ente encargado de aprobar la
creación de Autoridades Certificadoras (CA) en el país. Una CA es una entidad de confianza,
responsable de emitir y revocar los certificados digitales utilizados para firmar documentos
digitalmente, mitigar riesgos relacionados con el no repudio de las acciones realizadas por
parte del poseedor de un certificado digital e autenticar de forma inequívoca a un ciudadano
durante una transacción digital.
El Reglamento a la Ley de Certificados, Firmas Digitales y Documentos Electrónicos
[4] le confirió el grado de Autoridad Certificadora Raíz del SNCD a la DCFD. En la
actualidad existe un convenio de cooperación entre el MICITT y el Banco Central de Costa
Rica (BCCR), por lo que este último es el encargado de implementar, custodiar y operar la
raíz del Sistema.
Actualmente, la única Autoridad Certificadora registrada en el Sistema Nacional de
Certificación Digital para la emisión de certificados al público en general es administrada
por el Banco Central de Costa Rica y es conocida como CA-SINPE. Esta es la única CA
aprobada para la generación de certificados digitales a los ciudadanos. No obstante, la ley
permite la implementación de múltiples Autoridades Certificadoras, tanto en el sector público
como privado. Además incluye la posibilidad de la homologación de certificados generados
4
por Autoridades Certificadoras extranjeras. Cada una de estas Autoridades Certificadoras
debe cumplir con cada uno de los requisitos que defina el marco legal costarricense para
poder operar y emitir certificados digitales en Costa Rica.
1.2. Motivación
El Reglamento a la Ley de Certificados, Firmas Digitales y Documentos Electrónicos
[4], publicado inicialmente en el 2006, define los requisitos que debe cumplir una entidad
para poder registrarse como Autoridad Certificadora dentro del Sistema Nacional de
Certificación Digital:
Artículo 11. Comprobación de idoneidad técnica y administrativa. Para obtener la condición de certificador registrado, se requiere poseer idoneidad técnica y administrativa, que serán valoradas por el ECA, de conformidad con los lineamientos técnicos establecidos en las Normas INTE/ISO/IEC 170211 e INTE/ISO 211882 versión vigente, las políticas fijadas por la DCFD y los restantes requisitos que esa dependencia establezca, de acuerdo con su normativa específica.
El problema que surge actualmente es que, después de la experiencia de la
implementación de la Autoridad Certificadora del Banco Central y dado el interés de algunas
organizaciones nacionales e internacionales sobre los requisitos necesarios para implementar
una CA en Costa Rica, se ha observado que la definición de los requisitos estipulados en el
Artículo 11 del Reglamento a la Ley 8454 no son lo suficientemente claros, factibles y
apegados a la realidad y necesidades nacionales. Algunas de las situaciones que se han
encontrado son:
1 El estándar ISO 17021, Evaluación de la conformidad: requisitos para los organismos que realizan la auditoría y la certificación de sistemas de gestión y la especificación técnica [33], define los requisitos que debe tener una entidad para poder certificar sistemas de gestión de terceros. 2 El estándar ISO 21188, Infraestructura de llave pública para servicios financieros: Estructura de prácticas y políticas [15], define una serie de objetivos y procedimientos de control para la implementación de una Autoridad Certificadora en ambientes financieros.
5
§ No existe una lista claramente definida de los requisitos necesarios para implementar
una Autoridad Certificadora en Costa Rica. En general los requisitos se especifican
referenciando estándares y documentos, con múltiples referencias entre ellos,
elementos duplicados y elementos definidos de forma poco clara.
§ Existen diversos estándares a nivel internacional para la implementación y certificación
de Autoridades Certificadores, y de infraestructuras de llave pública en general que no
son mencionados en la legislación vigente, que podrían contener elementos relevantes
que podrían ayudar a mejorar la infraestructura de llave pública por ejemplo en
términos de seguridad, administración y procesos.
§ No existe un estudio o análisis que sustente la utilización de la norma ISO-21188 como
base de los requisitos de una Autoridad Certificadora en Costa Rica.
§ La norma ISO-21188 fue diseñada inicialmente como una guía de implementación y
auditoría para Autoridades Certificadores en ambientes financieros, no para
Autoridades Certificadores dentro de Infraestructuras de Llave Pública a nivel país, en
las cuáles se podría considerar el riesgo y el costo de una brecha de seguridad podría
ser más crítico.
§ No es claro dentro de la reglamentación vigente, e incluso a nivel de la industria, como
podría una Autoridad Certificadora obtener una auditoría con base en la norma ISO-
21188.
Este proyecto de investigación nace de la necesidad de sustentar si algún estándar
existente a nivel internacional puede ser utilizado como base para la definición de los
requisitos de implementación de una Autoridad Certificadora dentro del Sistema Nacional de
Certificación Digital. A partir del análisis realizado en este trabajo se podría tomar la decisión
de utilizar uno de los estándares existentes o de crear un esquema de certificación o estándar
propio que incluya los elementos pertinentes y necesarios para el correcto funcionamiento de
las Autoridades Certificadoras del SNCD.
6
1.3. Objetivos y metodología
El objetivo principal de este proyecto de investigación fue analizar estándares
internacionales para la certificación de Autoridades Certificadoras en infraestructuras de
llave pública y evaluar su aplicabilidad dentro del Sistema Nacional de Certificación Digital.
Con más detalle, los objetivos específicos durante el desarrollo de la investigación fueron:
§ Caracterizar al menos 3 estándares internacionales utilizados para certificar
Autoridades Certificadoras en el contexto de una infraestructura de PKI.
§ Identificar las políticas y requisitos de implementación necesarios para las
Autoridades Certificadoras del Sistema Nacional de Certificación Digital.
§ Evaluar la aplicabilidad de los estándares analizados en el Sistema Nacional de
Certificación Digital.
Para cumplir con los objetivos definidos, el proceso de investigación se dividió en las
siguientes etapas:
§ Recopilación y selección de los estándares internacionales para ser analizados.
§ Identificación de los requisitos y políticas necesarios para la implementación de una
Autoridad Certificadora a nivel nacional con base en la legislación vigente.
§ Análisis de la aplicabilidad de los estándares analizados con respecto a las políticas
y requisitos identificados a nivel nacional para la implementación de Autoridades
Certificadoras dentro del SNCD.
El proceso utilizado se muestra en la Figura 1. Las primeras dos etapas se realizaron de
forma independiente. El objetivo por un lado era encontrar los posibles estándares a evaluar
y por el otro la identificación de los requisitos requeridos para poder implementar una
Autoridad Certificadora en Costa Rica de forma legal y reconocida por la DCFD.
7
Figura 1. Metodología utilizada para el desarrollo de la investigación.
Con base en los resultados de estas dos etapas, se procedió a realizar un control cruzado,
verificando cada uno de los elementos que son requeridos contra los objetivos de control de
cada uno de los estándares evaluados, con el fin de determinar si:
§ ¿Existe algún estándar que contenga todos los requisitos que son necesarios para
implementar una CA en Costa Rica?
§ Si lo anterior no sucediera, ¿Cuál de los estándares tiene más elementos en común
con los requisitos nacionales?
§ ¿Existen elementos solicitados en los estándares que no son solicitados a nivel
nacional? En caso afirmativo, sería interesante analizar por qué no son solicitados.
§ ¿Existe alguna otra opción, diferente del estándar ISO-21188 para certificar las
implementaciones de una CA en Costa Rica?
Las respuestas a estas preguntas se presentan en este documento.
Recopilaciónde
Estándares
IdentificacióndeRequisitosNacionales
Análisisdelaaplicablidad decadaestándarconbaseenlos
requisitosidentificados
8
1.4. Alcance
En el contexto del Sistema Nacional de Certificación Digital hay diferentes actores:
§ Autoridades Certificadoras.
§ Autoridades de Registro.
§ Proveedores de Servicios.
§ Usuarios finales (ciudadanos y organizaciones).
Este proyecto de investigación se enfocó únicamente en el análisis de los requisitos y
estándares relacionados con las Autoridades Certificadoras dentro del Sistema Nacional de
Certificación Digital de Costa Rica. No se incluye dentro de este trabajo el análisis de los
requisitos o estándares relacionados con la implementación de Autoridades de Registro,
proveedores de servicios ni usuarios finales.
1.5. Organización del documento
Este documento se organiza de la siguiente manera. El capítulo 2 brinda un repaso de
conceptos básicos de seguridad, criptografía y PKI, necesarios para la comprensión de este
documento. El lector familiarizado con estos conceptos puede pasar directamente al capítulo
3, el cual presenta los resultados obtenidos en el proceso de identificación y selección de
estándares internacionales para la evaluación. En este capítulo se describen los estándares
seleccionados, y el proceso utilizado para su selección. El capítulo 4 describe el proceso de
identificación de los requisitos y políticas nacionales para la implementación de una
Autoridad Certificadora en Costa Rica. El capítulo 5 expone el análisis de aplicabilidad de
cada estándar analizado con respecto a las políticas nacionales identificadas. Finalmente, el
capítulo 6 resume las conclusiones obtenidas del trabajo realizado, menciona el impacto de
los resultados obtenidos y detalla algunos elementos que pueden realizarse a futuro para
continuar la investigación.
9
2. Marco teórico
Se presenta a continuación un breve resumen de los principales conceptos necesarios
para la comprensión de este documento. Se dividen estos conceptos en tres partes: seguridad,
criptografía e infraestructuras de llave pública. El lector con conocimientos en seguridad y
criptografía, pero sin experiencia en PKI puede saltar directamente a la sección 2.3.
2.1. Conceptos Básicos de Seguridad
Una amenaza (threat) es una potencial violación de la seguridad de un sistema. La
violación de seguridad no necesita concretarse para que la amenaza exista. El hecho de que
la violación pueda ocurrir significa que se debe estar preparado ante las acciones que podrían
causarla. Dichas acciones son llamadas ataques (attacks). Quienes ejecutan las acciones o
causan que sean ejecutadas son llamados atacantes (attackers) [5]. Shirey [6] divide las
amenazas en cuatro clases generales:
§ Divulgación (disclosure): acceso no autorizado de la información.
§ Engaño (deception): aceptación de datos falsos o modificados.
§ Interrupción (disruption): interrupción o prevención de una correcta operación.
§ Usurpación (usurpation): control no autorizado de alguna parte de un sistema.
Estas cuatro clases generales abarcan muchas amenazas comunes. Debido a que las amenazas
son ubicuas, una discusión introductoria de algunos ejemplos presentará problemas que son
recurrentes a lo largo del estudio de la seguridad computacional.
§ Intromisión (snooping): es la interceptación no autorizada de información, es una
forma de divulgación. Es un ataque pasivo, en el que alguna entidad está escuchando
(o escribiendo) comunicaciones o navegando a través de archivos o sistemas de
información. Las intervenciones activas y pasivas de líneas (wiretapping, passive
wiretapping) son una forma de intromisión en la cual una red es monitoreada. [5]
10
§ Alteración: es un cambio no autorizado de información, cubre tres clases de
amenazas. El objetivo podría ser el engaño (deception), en cuyo caso alguna entidad
confía en los datos modificados para determinar qué acción tomar, o bien,
información incorrecta es aceptada como correcta y liberada. Si los datos modificados
controlan la operación de un sistema, surgen las amenazas de interrupción
(disruption) y usurpación (usurpation). A diferencia de los ataques de intromisión, la
modificación se da de forma activa, como resultado de una entidad modificando la
información. Un ejemplo es el ataque de man-in-the-middle, en el cual un intruso lee
mensajes de un remitente y envía versiones posiblemente modificadas al recipiente,
con la esperanza de que tanto el recipiente como el remitente no se den cuenta de la
presencia del intermediario. [5]
§ Enmascaramiento (masquerading o spoofing): Es la suplantación de una entidad por
otra, es una forma de engaño y usurpación. Induce a la víctima para que crea en la
entidad con la cual se está comunicando, aunque es diferente a la esperada. Por
ejemplo, si un usuario trata de iniciar una sesión en una computadora a través de
Internet, pero en su lugar alcanza otra computadora que afirma ser la deseada, el
usuario ha sido engañado. Lo mismo ocurre si un usuario trata de leer un archivo pero
un atacante hace que el usuario reciba un archivo diferente. Este puede ser un ataque
pasivo, en cuyo caso el usuario no intenta autenticar el recipiente sino que
simplemente lo accede, pero la mayoría de los casos se da de forma activa, donde el
atacante da respuestas al usuario para engañar al usuario acerca de su identidad. [5]
§ Repudio de origen (repudiation of origin): consiste en la negación de que una
entidad envió o creó algo, a pesar de que si lo hizo. Es una forma de engaño. Una
variación de este ataque es negación de un usuario que creó información específica o
entidades como archivos. [5]
§ Negación de recibo (denial of receipt): consiste en negar el hecho de que una entidad
recibió alguna información o mensaje. Es una forma de engaño. [5]
11
Cada una de estas amenazas trata de hacer que un objetivo específico de seguridad
definido con anterioridad para el sistema se incumpla con el fin de obtener provecho de la
situación, por ejemplo de acceso a información confidencial o de perjudicar la disponibilidad
de un sistema de uso crítico.
2.1.1. Objetivos de Seguridad
La literatura clásica reconoce 3 objetivos fundamentales para la administración de la
seguridad de un sistema computacional [5]:
§ Confidencialidad
§ Integridad
§ Disponibilidad
La confidencialidad se refiere a la propiedad de no revelar datos o información a
personas o procesos sin autorización. La confidencialidad está muy relacionada a la
privacidad. La privacidad es la habilidad de un individuo o grupo de mantener información
acerca de sí mismos confidencial y controlar el acceso y uso de dicha información. La
confidencialidad se logra utilizando mecanismos de control de acceso. Por ejemplo se puede
utilizar criptografía para proteger la confidencialidad de la información. La integridad se
refiere a la propiedad de que los datos no han sido modificados por un tercero sin
conocimiento del emisor y receptor del archivo. Finalmente, la disponibilidad se refiere a la
habilidad de usar la información o recurso deseado cuando es necesario. [5]
Adicionalmente, en algunos sistemas son importantes dos objetivos más: autenticidad y
no repudio. La autenticidad es la capacidad de poder determinar de forma inequívoca el
origen de un conjunto de datos. El no repudio es una propiedad de los datos o procesos que
evita que una entidad niegue ser el autor de un conjunto de datos. Como se explicará más
adelante, estos dos objetivos son primordiales en el contexto de una Infraestructura de Llave
Pública.
12
Existen objetivos de seguridad adicionales. En general, los objetivos de seguridad
necesarios para un sistema están dados por los requerimientos del mismo. Durante el proceso
de diseño de un estrategia de seguridad, generalmente los objetivos de seguridad son
soportados a través de la definición de políticas de seguridad y la implementación de
mecanismos de control.
2.1.2. Políticas y Mecanismos
Una política de seguridad es una declaración de lo que es y lo que no es permitido. Las
políticas pueden ser descritas matemáticamente, como una lista de estados permitidos
(seguros) y estados no permitidos (no seguros). En la práctica, las políticas no son
especificadas de manera tan precisa, normalmente se describen en lenguaje natural e indican
lo que los usuarios y los sistemas tienen permitido hacer. La ambigüedad inherente en dichas
descripciones lleva a estados que no han sido clasificados como permitidos o no permitidos.
En general existen múltiples políticas para el aseguramiento de la seguridad de un sistema.
La escogencia de las políticas adecuadas y necesarias depende de la naturaleza del sistema,
las amenazas a las que está expuesto, los recursos disponibles, y el valor de la información
que maneja. [5]
Un mecanismo de seguridad es un método, herramienta, o procedimiento para hacer
cumplir una política de seguridad. Los mecanismos pueden ser no técnicos, como por
ejemplo requerir una comprobación de identidad antes de cambiar una contraseña. Uno de
los mecanismos utilizados para poder cumplir con todos los objetivos de seguridad descritos
en la sección anterior es la criptografía de llave pública.
A continuación, se presenta un breve resumen de los conceptos básicos de criptografía.
Posteriormente se explica como la criptografía de llave pública permite implementar los
objetivos de seguridad previamente descritos con el fin de asegurar un sistema de
información.
13
2.2. Conceptos Básicos de Criptografía
La palabra criptografía significa escritura oculta o secreta. La criptografía es
generalmente entendida como el cifrado y descifrado de mensajes privados [5]. Un mensaje
es cifrado para mantenerlo privado o para proteger su confidencialidad. Las técnicas de
criptografía modernas permiten además determinar si un mensaje ha sido modificado desde
que fue creado e identificar su remitente. Un mensaje que no ha sido alterado tiene integridad.
El conocimiento del origen de un mensaje es autenticación. Antes de describir los principales
conceptos de la criptografía de llave pública, se presenta un breve resumen de los conceptos
básicos de criptografía.
El componente básico de la criptografía es un sistema criptográfico. Un sistema
criptográfico es una quíntupla (E, D, M, K, C), donde M es el conjunto de textos planos, K
es el conjunto de llaves, C es el conjunto de textos cifrados, E: M x K – C es el conjunto de
funciones de cifrado y D: C x K – M es el conjunto de funciones de descifrado [5] [7]. Un
algoritmo criptográfico define una serie de pasos que un remitente lleva a cabo para cifrar un
mensaje privado así como los pasos que el destinatario lleva a cabo para descifrarlo. La
mayoría de los algoritmos criptográficos utilizan dos entradas para cifrar el mensaje, proteger
su integridad o autenticar su fuente. La primera entrada es el contenido del mensaje y la
segunda un valor secreto conocido como llave. Existen diferentes tipos de algoritmos
criptográficos que se diferencian por los servicios de seguridad que proveen y el tipo de llaves
que cada uno emplea.
El objetivo de la criptografía es mantener la información cifrada secreta. Asumiendo que
un adversario desea romper un texto cifrado, la práctica de la criptografía estándar es asumir
que el adversario conoce el algoritmo utilizado para cifrar el texto plano, pero no la llave
criptográfica (conoce D y E). El adversario puede entonces utilizar tres tipos de ataques:
§ En un ataque de solo texto cifrado, el adversario tiene solo el texto cifrado. Su objetivo
es encontrar el texto plano correspondiente. Si es posible, puede tratar de encontrar la
llave.
14
§ En un ataque de texto plano conocido, el adversario tiene el texto cifrado y el texto plano
que fue cifrado. Su meta es encontrar la llave que fue utilizada.
§ En un ataque de texto plano escogido, el adversario puede preguntar por textos planos
específicos para que sean cifrados y recibe los textos cifrados correspondientes. Su meta
es encontrar la llave que fue utilizada.
Un buen sistema criptográfico protege contra los tres tipos de ataques. Los ataques
utilizan métodos matemáticos y estadísticos. Los métodos estadísticos hacen supuestos sobre
las estadísticas del lenguaje del texto plano y examinan el texto cifrado para correlacionar
sus propiedades con los supuestos. Los supuestos son colectivamente llamados un modelo
del lenguaje. Por ejemplo la Tabla 1 muestra el modelo del lenguaje para el idioma español.
Tabla 1. Modelo del idioma español. Muestra la frecuencia de cada uno de los caracteres del lenguaje. Tomado de [8]
a 0.17 d 0.38 , 0.14 z 0.03 e 0.11 u 0.33 q 0.10 ; 0.02 o 0.10 t 0.31 v 0.08 ñ 0.02 s 0.07 c 0.30 g 0.08 x 0.007 r 0.058 m 0.21 h 0.07 : 0.054 n 0.51 p 0.19 y 0.07 k 0.0003 i 0.49 b 0.15 f 0.04 w 0.0001 l 0.48 . 0.15 j 0.03
El uso de la criptografía para mantener la confidencialidad de un mensaje es mucho más
antiguo que el desarrollo de la informática. Algunos de los algoritmos clásicos para el cifrado
de información fueron desarrollados por civilizaciones antiguas (griegos y romanos) para el
intercambio de órdenes de guerra y mensajes diplomáticos. Debido a que el proceso de
descifrado tenía que ser manual, el componente principal de estos algoritmos era la
substitución o transposición de los caracteres del mensaje [9].
15
2.2.1. Sistemas Criptográficos Clásicos
Los sistemas criptográficos clásicos, también llamados sistemas criptográficos de una
llave o simétricos, son sistemas criptográficos que usan la misma llave para cifrar y descifrar.
El cifrado simétrico es una forma de cambiar texto plano a texto cifrado utilizando una llave
compartida. La llave es solamente conocida por el remitente y el destinatario. Ambas partes
utilizan la misma llave para cifrar y descifrar. El proceso para este tipo de algoritmos se
muestra en la Figura 2. En esta Alice y Bob tienen que compartir la misma llave para poder
cifrar y descifrar los mensajes enviados.
Para un cifrado simétrico se pueden utilizar diferentes sistemas de cifrado, incluyendo
substituciones directas y transformaciones. Todos los enfoques tienen un elemento en común:
el uso de un secreto compartido, que también constituye un punto de vulnerabilidad. El
objetivo para romper esta forma de cifrado es obtener la llave compartida. De esta forma,
mecanismos de seguridad deben ser utilizados para intercambiar el secreto compartido.
Figura 2. Algoritmo de Cifrado Simétrico
Proceso de cifrado y descifrado utilizando un algoritmo basado en criptografía simétrica. Note que Alice y Bob tienen que tener acceso a la misma llave. Tomado de
[10]
Texto Plano
Texto Cifrado
Llave
Alice
Algoritmo de Cifrado
Texto Plano
Llave
Bob
Texto Cifrado
Algoritmo de Descifrado
16
Existen dos tipos de básicos de cifrados clásicos: cifrados de transposición y cifrados de
substitución. Un cifrado de transposición reordena los caracteres en el texto plano para
formar el texto cifrado. Las letras no son cambiadas, solamente reubicadas.
Matemáticamente, la llave de un cifrado de transposición es una función de permutación.
Debido a que la permutación no afecta la frecuencia de los caracteres del texto plano, un
cifrado de transposición puede ser detectado comparando las frecuencias de los caracteres
con un modelo del lenguaje. Un ataque a un cifrado de transposición requiere reordenar las
letras del texto cifrado. Este proceso se conoce como basado en n-gramas y usa tablas de
frecuencias para identificar n-gramas comunes. El criptoanálisis organiza las letras de forma
que los caracteres en el texto cifrado formen algunos n-gramas con la más alta frecuencia.
Este proceso es repetido, utilizando diferentes n-gramas, hasta que el patrón de transposición
es encontrado. Un cifrado de sustitución cambia caracteres en el texto plano para producir el
texto cifrado. La estadística indica cuál es la llave que pudo haber sido utilizada con más
probabilidad. Aunque dicha llave no sea la correcta, las estadísticas reducen en la mayoría
de los casos, el número necesario de intentos para encontrarla. [5]
La ventaja principal de utilizar un cifrado simétrico es su simplicidad, lo cual incide en
su rendimiento. La fortaleza del cifrado depende de la longitud de la llave y no del algoritmo
de cifrado. Entre más largo sea el secreto compartido, más tiempo le tomará al atacante
decodificarlo, y consecuentemente, más fuerte será la confidencialidad provista. La principal
desventaja de un cifrado simétrico es la distribución del secreto compartido. Para que esta
forma de cifrado funcione, todas las partes deben conocer la llave común. Esto crea una serie
de problemas que tienen un tema en común: disponibilidad versus seguridad. Por un lado, se
requiere de un método seguro para entregar el secreto compartido, lo cual se concentra en la
disponibilidad de la llave por parte de todos los participantes. Si el secreto compartido no se
entrega a todas las partes, el cifrado y descifrado no puede llevarse a cabo. Por otro lado, se
da el problema de seguridad con respecto al conocimiento del secreto compartido. Si el
secreto compartido es comprometido por un mecanismo de fuerza bruta, análisis
criptográfico o exposición errónea, todas las transmisiones serán comprometidas.
17
Esto introduce otro desafío relacionado, el cual es llegar a un secreto compartido lo
suficientemente fuerte. Si el secreto compartido es comprometido, todas las conversaciones
podrían ser leídas. En este tipo de escenarios, el problema principal siempre es el mecanismo
de distribución de la llave. Al utilizar una llave que todos los miembros del sistema tienen
que conocer para poder cifrar y descifrar los mensajes, se trasladan las vulnerabilidades de
la transmisión del mensaje a la transmisión de la llave.
En 1976, Diffie y Hellman [7] propusieron un enfoque diferente para solucionar el
problema de la distribución de las llave. Diseñaron un algoritmo que distingue entre la llave
utilizada para el cifrado y la utilizada para el descifrado de la información. En contraposición
con los algoritmos simétricos (que pasaron a conocerse como algoritmos de llave privada),
los algoritmos basados en el enfoque de Diffie y Hellman son algoritmos asimétricos o de
llave pública [5] [7].
2.2.2. Criptografía de Llave Pública
La criptografía de llave pública utiliza múltiples llaves en lugar de un único secreto
compartido. Cada emisor tiene dos llaves: una llave pública y una llave privada. La llave
pública está disponible para cualquier persona y se distribuye de forma libre. La llave privada
se mantiene oculta y solo el emisor la conoce. El que la llave privada sea conocida solo por
el emisor es una suposición crítica del cifrado asimétrico. Otro aspecto esencial es que la
llave privada no se puede obtener a partir de la llave pública. [5]
En general, la criptografía de llave pública se utiliza para dos escenarios: el cifrado de
llave pública y las firmas digitales. En el cifrado de llave pública el proceso de convertir un
texto plano en texto cifrado se realiza de manera diferente a un cifrado simétrico.
Dependiendo del propósito de la transmisión, puede utilizarse la llave privada o la llave
pública para cifrar los datos. El destinatario utiliza la llave opuesta para descifrar los datos.
Por su alto costo computacional, el cifrado de llave pública se utiliza generalmente para
compartir una llave entre los distintos participantes de la comunicación, los cuales una vez
18
recibida la llave, proceden a utilizar un algoritmo de cifrado simétrico para el resto de las
comunicaciones [10].
A partir de este esquema es posible entonces utilizar la llave privada para cifrar algo y
cualquiera que tenga acceso a la llave pública que corresponde a la privada que fue utilizada
para el cifrado puede asegurarse que el mensaje fue emitido por la persona en posesión de la
llave privada y que además podría verificar la integridad del mensaje. A este proceso se le
conoce como firmar digitalmente un mensaje.
2.2.3. Firmas Digitales
La criptografía de llave pública provee la base para implementar firmas digitales. La
llave privada es utilizada para generar firmas y la llave pública es utilizada para validarlas.
En las aplicaciones reales, los mensajes no son firmados digitalmente de manera directa. En
su lugar, el mensaje es resumido utilizando una función hash de un solo sentido y el resultado,
que se denomina el resumen del mensaje (message digest), es firmado. [10]
El tipo de algoritmo más utilizado para la implementación de firmas digitales es la firma
digital con recuperación de mensaje. Con los algoritmos de firma digital con recuperación de
mensaje, el remitente firma cifrando el resumen del mensaje con su propia llave privada. El
destinatario valida la firma comparando el resumen del mensaje que calcula localmente con
el que obtiene al descifrar la firma incorporada en el mensaje utilizando la llave pública del
remitente. Si los dos resúmenes coinciden, la firma digital es válida.
El algoritmo RSA es el algoritmo de firma digital con recuperación de mensaje más
conocido. La Figura 3 muestra el proceso utilizado por Alice y Bob para firmar y verificar
una firma utilizando el algoritmo de RSA. En primer lugar, Alice calcula un hash del mensaje
que desea firmar. Luego cifra este mensaje con su propia llave privada. Alice envía el
mensaje junto con la firma (el resultado del hash cifrado) a Bob. Bob recibe el mensaje, y en
primera instancia calcula un hash del mensaje recibido (sin la firma) y luego descifra la firma
enviada por Alice utilizando la llave pública de Alice. Si ambos hashes coinciden, entonces
19
Bob sabe que el mensaje es íntegro (no fue modificado en el camino) y que Alice fue la que
lo envió (debido a que se usó su llave privada para firmar).
Figura 3. Proceso de verificación de una firma digital.
Proceso utilizado para generar una firma digital y verificarla utilizando el algoritmo de RSA. Tomada de [10].
Todos los algoritmos de firma digital requieren autenticación de la llave pública. El
destinatario debe saber que la llave pública que está utilizando corresponde a la llave privada
Alice
Mensaje
Hash
Resumen
Cifrar
Firma
Llave Privada
Bob
Mensaje
Hash
Resumen 2 Descifrar
Llave Privada
Resumen 1 Si coinciden entonces la
firma es válida
Firma
20
conocida sólo por el remitente. De no ser este el caso, el destinatario no tiene garantía sobre
el origen del mensaje. El destinatario tiene evidencia de que el mensaje no ha sido modificado
desde que el firmante firmó el mensaje, pero no sabe quién lo firmó. El destinatario necesita
un mecanismo adicional para complementar los algoritmos de firma digital. Necesita un
mecanismo que conecte la llave pública con el usuario que posee la llave privada
correspondiente de forma confiable [10]. Para este último propósito es que se utilizan
certificados digitales.
2.3. Certificados Digitales
El principal problema de utilizar la criptografía de llave pública para la validación de
firmas digitales, es que el usuario que desea validar una firma no tiene certeza de que la llave
pública que está utilizando efectivamente pertenece al individuo que piensa. Un certificado
digital establece un vínculo entre una identidad, que puede ser un individuo o un dispositivo
de cualquier tipo, y el material electrónico correspondiente . En este caso, el material es
información criptográfica, la llave pública asociada con la identidad validada por el
certificado [11].
Un certificado digital es un conjunto de información digital independiente, combinada
y firmada por una autoridad. Una autoridad es un tercero de confianza o una entidad
administrativa que la confianza de los usuarios.
Idealmente un certificado digital debería tener las siguientes características [10]:
§ Sería un objeto completamente digital, para poder ser distribuido por red y procesado
de manera automática.
§ Contendría el nombre del usuario que tiene en su posesión la llave privada,
identificaría la compañía u organización del usuario, así como su información de
contacto.
§ Sería fácil de determinar si el certificado fue emitido recientemente.
21
§ Sería creado por una parte de confianza en lugar del usuario que tiene en su posesión
la llave privada.
§ Debería ser fácil de diferenciar diferentes certificados, inclusive aquellos creados
para el mismo usuario.
§ Sería fácil determinar si el certificado es genuino o falsificado.
§ Sería a prueba de alteraciones de manera que no se podría cambiar su contenido.
§ Podría determinarse de forma inmediata si la información en el certificado no está
actualizada.
§ Podrían determinarse las aplicaciones para las cuales el certificado aplica basándose
en su contenido.
Con base en los elementos anteriores un certificado digital típico contiene la siguiente
información:
§ Identidad: un nombre o una referencia a un objeto, persona o material.
§ Atributos: los atributos se adjuntan a la identidad o a los usos autorizados del
certificado.
§ Llave pública: la llave pública realiza una serie de operaciones criptográficas.
§ Firma: la firma corresponde a una Autoridad Certificadora (CA por sus siglas en
inglés) y cubre toda la información anterior. La firma autentica el vínculo entre toda
la información contenida en el paquete.
La Tabla 2 muestra la estructura típica de un certificado digital. A continuación se
presenta una breve descripción de cada campo basado en el estándar RFC-5280 [12]:
• Versión: Actualmente existen tres versiones del estándar X.509. Desde 1996, la
versión más utilizada para propósitos de Internet es la v3. Las diferencias entre
versiones son campos adicionales.
22
• Número de serie: El número de serie identifica de forma única un certificado entre
todos los certificados emitidos por una CA.
• ID Algoritmo: es el identificador del algoritmo utilizando por la CA para firmar el
certificado.
Tabla 2. Estructura típica de un certificado digital.
Tomado de [11].
Componente Campos
Certificado
• Versión
• Número de Serie
• ID del Algoritmo
• Editor
• Periodo de Validez
§ No Antes
§ No Después
• Nombre del Sujeto
• Información de la Llave Pública del Sujeto
§ Algoritmo de Llave Pública
§ Llave Pública del Sujeto
• Identificador Único del Editor (opcional, versión 2
en adelante)
• Identificador Único del Sujeto (opcional, versión 2
en adelante)
• Extensiones (opcional, versión 3 en adelante)
Algoritmo de Firma del Certificado
El algoritmo utilizado para generar la firma del certificado, por ejemplo SHA1 con RSA.
Firma del Certificado La firma digital generada.
23
• Editor: Contiene información sobre la CA que emitió y firmó el certificado.
• Período de Validez: El periodo de validez define el intervalo de tiempo durante el
cual la CA garantiza que mantendrá la información sobre el status de un certificado.
Después de la fecha de expiración el certificado es inválido. Este campo contiene
dos fechas expresadas en tiempo universal (UTC/GMT): no antes y no después.
• Nombre del sujeto: identifica la entidad a la que pertenece la llave pública. El
nombre del sujeto toma la forma de un nombre distinguido (DN) del estándar X.500
[13]. Las estructuras típicas de Nombres Distinguidos incluyen País, Organización,
Unidad Organizacional y Nombre Común.
• Algoritmo de llave pública: incluye el algoritmo en el cual puede utilizarse la llave
pública, que puede ser RSA o DSA.
• Llave pública del sujeto: contiene la llave pública asociada con la entidad
identificada en el campo del Nombre del Sujeto.
• Identificador único del editor: es un identificador único utilizado para identificar la
CA en el caso en que múltiples CAs tengan nombres similares. Este identificador es
una referencia al identificador único del sujeto incluído en el certificado de la CA.
• El identificador único del sujeto: es un identificador único asociado a la entidad.
Este campo opcional puede ser utilizado en el caso en que múltiples entidades tienen
nombres de sujetos similares.
• Algoritmo de la firma del certificado: es el algoritmo utilizado por la CA para firmar
el certificado. Un ejemplo de dicho algoritmo es SHA1 con cifrado RSA. Este
campo debe contener el mismo identificador de algoritmo que el utilizado en el ID
del algoritmo.
• Firma del certificado: contiene la firma digital calculada sobre todos los campos del
certificado, y es agregada por la CA cuando crea el certificado. Al generar esta
24
firma, una CA certifica la validez y autenticidad de la información en los campos.
Particularmente, la CA certifica el vínculo entre el material de llave pública y el
sujeto del certificado. Al momento de recibir un certificado, uno de los primeros
pasos es verificar la firma para asegurarse que el certificado no ha sido alterado.
El campo de extensiones provee una forma de asociar diversos atributos al usuario o a
llaves públicas. Las extensiones privadas pueden ser definidas según como sean requeridas
por sus implementaciones. Cada extensión es marcada como crítica o no crítica. Si un sistema
no puede procesar una extensión crítica, éste debe rechazar el certificado. En el caso de las
extensiones no críticas, éstas pueden ser ignoradas en situaciones similares. En la Tabla 3 se
presentan las extensiones más comunes utilizadas en implementaciones de PKI.
2.3.1. Estado de un Certificado
En general un certificado digital puede tener varios estados: activo, revocado, expirado
o suspendido. Es importante destacar que las transiciones de un estado a otro deben ser
manejadas por el emisor del certificado digital, ya que éste es el encargado de proveer
información sobre los certificados que ha generado.
La Lista de Revocación de Certificados (CRL por sus siglas en inglés), es la herramienta
básica para distribuir información sobre el estado de certificados digitales. La CRL contiene
una lista de números seriales de certificados que todavía no han expirado, que no deben ser
confiados. Un CRL es un objeto digital que el emisor de certificados digitales puede
distribuir, y los usuarios pueden procesar electrónicamente. Cualquier alteración en una CRL
es evidente ya que el emisor la firma, al igual que un certificado. En lugar de enviar por
correo la CRL a todos los posibles usuarios, el emisor genera una CRL frecuentemente y la
publica en Internet. El emisor incluye en la CRL la fecha de emisión, así como la fecha de
expiración, de forma que es posible asegurarse de que la información está actualizada.
Los CRLs son herramientas para la validación del estado de un certificado. Existe un
protocolo llamado Online Certificate Status Protocol (OCSP) que permite la verificación en
25
línea del estado de un certificado. Este protocolo se describe en el RFC 6960 y está en el
registro de estándares de Internet. Los mensajes OCSP habitualmente se transmiten sobre el
protocolo HTTP.
Tabla 3. Descripción de extensiones de certificados típicamente utilizadas.
Tomado de [11].
Extensión Descripción Identificador de
la Llave de la Autoridad
Provee una forma de identificar de forma única el par de llaves utilizado para firmar un certificado. Este campo es útil cuando la CA tiene múltiples certificados
Identificador de la Llave del
Sujeto
Provee una forma de identificar certificados que contienen una llave pública en particular. Esta extensión es obligatoria para los certificados de las CA y opcional para los otros usuarios.
Uso de la Llave Define el uso que puede dársele a la llave contenida en el certificado. Usos típicos incluyen cifrado, firmas digitales, firmado CRL y firmado de certificados.
Nombre Alternativo del
Sujeto
Asocia identidades con el sujeto del certificado. Estas identidades pueden ser direcciones de correo electrónico, nombres DNS o direcciones IP.
Restricciones Básicas
Identifica si el sujeto del certificado es una Autoridad Certificadora, la cual tiene permitido emitir certificados hijos, y la profundidad máxima válida de la cadena de certificación, incluyendo el certificado en cuestión.
Usos Extendidos de
la Llave
Indica propósitos para los cuales la llave pública certificada puede ser utilizada, de forma adicional o reemplazando los propósitos básicos indicados en la extensión de usos de la llave. Ejemplos de estos propósitos incluyen Autenticación TLS de Servidor Web, Autenticación TLS de Cliente Web, firmado de código ejecutable descargable, protección de correo electrónico y firmado de respuestas OCSP.
Puntos de Distribución
CRL
Define cómo la información CRL debe ser recuperada. Este campo contiene principalmente HTTP o LDAP URI.
La Figura 4 se muestra a modo de ejemplo el contenido del Certificado Raíz del Sistema
Nacional de Certificación Digital de Costa Rica.
26
Figura 4. Contenido del Certificado Digital de la CA Raíz del Sistema Nacional de
Certificación Digital de Costa Rica.
27
El uso de certificados digitales permite resolver el problema de la verificación de la llave
pública. Sin embargo, el uso de certificados digitales para la implementación de firmas
digitales y otros servicios de seguridad depende totalmente de la entidad que genera los
certificados digitales. Todos los usuarios de los certificados tienen que confiar en que esta
entidad:
§ Verifica de manera correcta la identidad de los individuos que solicitan un certificado
digital.
§ Provee un mecanismo para revocar certificados que han sido expuestos o que vencen.
§ Provee un mecanismo para verificar el estado de un certificado.
Para la implementación de todos estos mecanismos se utilizan las Infraestructuras de Llave
Pública.
2.4. Infraestructura de Llave Pública
Una Infraestructura de Llave Pública (PKI por sus siglas en inglés) es un sistema que
utiliza certificados digitales emitidos por una entidad de confianza que se encarga de validar
y asegurar la identidad y validez de los certificados emitidos. Es difícil construir un único
componente que pueda crear y distribuir de manera segura certificados digitales. Las
infraestructuras de llave pública están constituídas por una variedad de componentes, cada
uno de los cuales está diseñado para llevar a cabo un conjunto pequeño de tareas. Existen
cuatro componentes funcionales básicos en un PKI [11]:
§ La Autoridad Certificadora
§ La Autoridad de Registro
§ El repositorio
§ El archivo
28
En el nivel más sencillo, siempre existen dos usuarios distintos en una transacción
habilitada por PKI. El primer usuario tiene una llave privada y es el sujeto de un certificado,
el cual contiene la llave pública correspondiente. Este usuario es llamado el subscriptor o
titular del certificado y participa en la transacción utilizando la llave privada. El segundo
usuario obtiene el certificado y utiliza la correspondiente llave pública para participar en la
transacción. El segundo usuario es llamado la parte que confía o usuario del certificado. La
Figura 5 muestra este proceso y además los distintos componentes y actores de una PKI. Se
describen a continuación cada uno de los componentes funcionales de una Infraestructura de
Llave Pública.
2.4.1. Autoridad Certificadora
La Autoridad Certificadora (CA por sus siglas en inglés) es el componente fundamental
de una infraestructura de llave pública. La CA es una colección de hardware, software, y las
personas que los operan. La CA es conocida por dos atributos, su nombre y su llave pública.
La CA lleva a cabo cuatro funciones principales:
§ Emite certificados: crea los certificados de los subscriptores y los firma.
§ Mantiene la información del estado de los certificados y emite CRLs.
§ Publica sus certificados actuales, que no han expirado, y CRLs, accesibles a los
usuarios para que puedan obtener la información requerida para implementar sus
servicios de seguridad.
§ Mantiene archivos de la información de los estados de los certificados, ya sea
expirados o revocados, que emitió.
Cada una de estas funciones define una serie de responsabilidades y requerimientos sobre la
CA.
29
Autoridad de políticas
Límite del CPS
Autoridad Certificadora
Registro
Emisor de Certificados
Fabricante de Certificados
Parte Autorizada
(Solicitud de revocación)
(Solicitud de revocación)
(Gestión de solicitud de certificado)
Servicio de validación
interno
(Estado de certificados y/o CRL)
(Validación de certificados)
(Actualizaciones de estado de certificados)
(Dispositivo de Suscriptor)
Servicio de validación
externo
Parte que confía
Suscriptor /sujeto
Relaciones de entidades finales
(CRL)
(OCSP)
CP CP CP
Repositorio
Figura 5. Infraestructura típica de llave pública.
Muestra los distintos procesos y actores de una Infraestructura de Llave Pública. Tomado de [15].
30
Una CA puede emitir certificados a usuarios, otras CAs o a ambos. Cuando una CA
emite un certificado, está afirmando que el sujeto, que es la entidad nombrada en el
certificado, tiene la llave privada correspondiente a la llave pública contenida en el
certificado. Si la CA incluye información adicional en el certificado, la CA está afirmando
que dicha información corresponde al mismo sujeto. Esta información adicional podría ser
información de contacto, como una dirección de correo electrónico, o información de
políticas, como los tipos de aplicaciones que pueden llevarse a cabo con la llave pública en
cuestión. Cuando el sujeto del certificado es otra CA, el emisor está afirmando que los
certificados emitidos por la otra CA son confiables. Al emitir el certificado la CA agrega su
nombre y la ubicación en donde acceder los CRL que genera y los firma con su llave privada.
Una vez que los usuarios establecen que confían en una CA, de manera directa o bien, por
medio de una serie de certificados, los usuarios pueden confiar en los certificados emitidos
por dicha CA.
Los usuarios pueden identificar los certificados emitidos por dicha CA comparando su
nombre. Para asegurarse que el certificado es genuino, los usuarios verifican la firma
utilizando la llave pública de la CA. El nombre de la CA generalmente es información
pública, y la firma de la CA es la base de confianza de los certificados. Si un atacante obtiene
la llave privada de la CA, los usuarios confiarán en los certificados que el atacante genera
como si los hubiera generado la CA. La primera y principal responsabilidad de la CA es
proteger su llave privada. Para proteger la llave privada, una CA debe proteger la llave
privada cuando esté en uso y cuando esté almacenada.
Para cumplir con este requerimiento, la CA confía en un módulo criptográfico. Los
módulos criptográficos generan llaves, protegen llaves privadas e implementan algoritmos
criptográficos. Pueden ser implementados en hardware, software o una combinación de
ambos. Los módulos criptográficos implementados en software son programas que corren en
un sistema de computadora. Los módulos criptográficos implementados en hardware, como
tarjetas inteligentes y tarjetas PCMCIA, realizan operaciones criptográficas en un procesador
externo. Los módulos criptográficos implementados por hardware mantienen la llave privada
31
fuera de la memoria del sistema anfitrión, por lo que su seguridad depende menos del sistema
operativo.
Los módulos criptográficos pueden ofrecer niveles de protección variantes debido a
defectos en su diseño o implementación. El Instituto Nacional de Estándares y Tecnología
(NIST por sus siglas en inglés) desarrolló FIPS 140, Requerimientos de Seguridad para
Módulos Criptográficos, el cual especifica cuatro niveles de seguridad incrementales para
módulos criptográficos. NIST y el Organización Canadiense de Seguridad en las
Comunicaciones (CSE por sus siglas en inglés), acredita laboratorios de terceros para realizar
pruebas de validación de módulos criptográficos contra el estándar FIPS 140.
La llave privada de una CA está en riesgo cuando está almacenada en memoria del
sistema anfitrión o en un módulo criptográfico comprometido. Una CA debe siempre utilizar
un módulo criptográfico implementado por hardware validado para generar su llave privada
y para protegerla cuando se encuentra almacenada o en uso. Como mínimo, el módulo debe
cumplir el nivel 2 del FIPS 140. Niveles mayores podrían ser requeridos si la CA está ubicada
en un sitio donde la seguridad física es una debilidad.
La CA, como el tercero de confianza por parte de los demás actores, debe siempre
verificar la información en un certificado antes de que éste sea emitido. Verificar la identidad
de un usuario, su información personal e información de políticas es diferente de proteger la
llave privada de la CA. Dicha verificación es un problema externo y depende de información
provista por otras partes fuera del personal operacional de la CA. Algunos de los contenidos
del certificado pueden ser verificados por la CA utilizando mecanismos técnicos. La CA
puede utilizar el mecanismo de firma digital para asegurar que el usuario tiene la llave privada
correspondiente a la llave pública en el certificado. Este proceso de verificación es llamado
prueba de posesión. Además de la exactitud de la información, los contenidos de los
certificados y CRLs deben también reflejar el perfil del certificado de la CA. Una CA
especifica los tipos de información que incluirá en los certificados.
32
La CA también se debe asegurar que todos los certificados y CRLs que emite están de
acuerdo con su perfil de certificado. Para poder asegurar que una CA emite certificados y
CRLs que están de acuerdo con su perfil, una CA lleva a cabo dos acciones: proteger la
integridad del perfil y verificar que cada uno y todos los certificados y CRLs se ajustan al
perfil. Para proteger la integridad del perfil, la CA restringe el acceso a los componentes de
la CA. Estas restricciones pueden ser físicas (por ejemplo, cuartos cerrados y resguardados,
acceso con llave), restricciones lógicas (como firewalls), o restricciones de procedimiento.
Restricciones de procedimiento podrían incluir un control de dos personas (por ejemplo,
requerir dos miembros del personal de la CA para modificar el sistema) o separación de tareas
(por ejemplo, prevenir que operadores del sistema aprueben las bitácoras de auditoría). De
manera similar a los certificados, los contenidos de las CRLs deben ser correctos.
Una CA debe mantener una la lista de certificados que ya no deben ser confiados.
Errores de omisión pueden causar que un usuario acepte un certificado no válido, lo cual
resultaría en una pérdida de seguridad. Listar certificados de confianza o fechas incorrectas
de revocación podría causar que un usuario rechace un certificado válido, resultando en una
negación de servicio.
Otra responsabilidad de una CA es distribuir sus certificados y CRLs. Cuando una CA
da servicio a una comunidad sin restricciones de usuarios, la distribución de certificados y
CRLs hacen referencia a disponibilidad y rendimiento, no a seguridad. No hay requerimiento
de restringir acceso a los certificados y CRLs ya que éstos no necesitan ser secretos. Un
atacante podría negar el servicio a usuarios eliminando o modificando información, pero el
atacante no podría hacerlos confiar en la información alterada sin obtener la llave privada de
la CA.
Una CA podría restringir sus servicios a una comunidad de usuarios cerrada. En este
caso, la CA podría desear que un atacante no tenga acceso a los certificados. Para esto la CA
podría asegurar la distribución de los certificados y CRLs. La integridad de los certificados
y de las CRLs no está en riesgo, pero la CA podría decidir no publicar la información que
33
éstos contienen. Por ejemplo, si los certificados de una compañía implícitamente identifican
su personal de investigación, esto podría ser explotado por un competidor. El competidor
podría determinar los tipos de proyectos de investigación por sus antecedentes o simplemente
tratando de contratar al personal.
Finalmente, una CA es el mantenimiento de suficiente información de archivo para
establecer la validez de certificados después de haber expirado. La CA necesita mantener
información para identificar el firmante de un documento antiguo basándose en un certificado
expirado. Para poder realizar esto, el archivo debe identificar la persona o sistema nombrado
en un certificado, establecer que hizo la solicitud del certificado, y mostrar que el certificado
era válido en el momento en que el documento fue firmado. El archivo debe también incluir
cualquier información sobre la revocación del certificado.
2.4.2. Autoridades Certificadoras Subordinadas (Sub-CA)
Las Autoridades Certificadoras Subordinadas surgen ante la necesidad de introducir
niveles jerárquicos en las funciones de la autoridad certificadora, debido al incremento en el
número de usuarios potenciales o inscritos. Los roles y funciones de una sub-CA son las
mismas que las de una CA: actuar como una autoridad de confianza, verificar identidades de
solicitantes y emitir de certificados. La única diferencia es que una CA puede verse como un
componente de PKI autónomo, mientras que una sub-CA es siempre hija de una CA.
A partir del concepto de sub-CA se pueden generar jerarquías dentro de la infraestructura
de llave pública. CA adicionales son creadas para efectos de escalabilidad y administración.
Las PKI jerárquicas utilizan un modelo de árbol con la CA raíz en el nivel más alto, y sub-
CAs en los niveles intermediarios. La CA en el tope es el punto central de agregación, sin
embargo, puede delegar parte de sus responsabilidades a las CAs subordinadas de manera
que la escalabilidad pueda ser restaurada. La Figura 6 muestra la jerarquía de la
infraestructura de llave pública del Sistema Nacional de Certificación Digital de Costa Rica.
34
En una infraestructura jerárquica no se está limitado a un único nivel de subordinación,
como se muestra en la Figura 6. Es común tener varias capas de sub-CAs. Además, las
diversas ramas no deben ser simétricas, el número de niveles tanto horizontales como
verticales pueden ser diferentes en cada rama. Una ventaja de utilizar jerarquías PKI es que
permiten poner la CA raíz fuera de línea, de manera que la seguridad se incrementa. Si una
sub-CA es comprometida, solamente el subárbol correspondiente sería impactado.
Figura 6. Jerarquía de la Infraestructura de Llave Pública del Sistema Nacional de
Certificación Digital (Elaboración propia).
2.4.3. Autoridad de Registro
Una Autoridad de Registro (RA por sus siglas en inglés), es también un hijo en la
jerarquía de una CA o sub-CA, sin embargo, sus roles y funciones son más limitadas. Una
Autoridad de Registro recibe delegación sólo de tareas administrativas como recibir
solicitudes de certificados o verificar la identidad del solicitante. Una vez que la RA ha
CARaíz
CAPersonaFísica
CAEmisora(BCCR)
AutoridaddeRegistro(Bancos)
UsuarioFinal
CAPersonaJurídica
CAEmisora(BCCR)
AutoridaddeRegistro(BCCR)
UsuarioFinal
35
completado sus tareas, contacta a su CA o sub-CA padre, la cual crea y emite el certificado.
El certificado es retornado a la RA, la cual maneja la distribución final al solicitante.
Una RA es una interfaz a la CA. El solicitante únicamente necesita establecer una
relación de confianza con la RA para autenticar la transacción, porque la autoridad de registro
no firma ningún certificado. Esto significa que muchas RAs pueden trabajar para la misma
CA, o una RA puede ser reemplazada fácilmente por otra. El objetivo principal de una RA
es reducir la carga en la CA delegando algunas de las tareas administrativas. [10]
2.4.4. Repositorio y Archivo
Un repositorio distribuye certificados y CRLs. Un repositorio acepta certificados y
CRLs de una o más CAs y los hace disponibles a otras partes que los necesitan para
implementar sus servicios de seguridad. Un repositorio es un sistema, y es conocido por su
dirección y su protocolo de acceso. Un repositorio provee certificados y CRLs cuando se le
solicita. Las solicitudes podrían estar basadas en el nombre de un usuario o CA u otra
información. Los repositorios no son entidades de confianza, el usuario acepta los
certificados y CRLs porque la CA los ha firmado.
Un archivo acepta la responsabilidad de almacenamiento de información de archivo a
largo plazo, en nombre de la CA. Un archivo afirma que la información era buena en el
momento en que fue recibida, y no ha sido modificada mientras ha estado en el archivo. La
información provista por la CA al repositorio debe ser suficiente para determinar si un
certificado fue emitido por la CA, como es especificado en el certificado, y si era válido en
ese momento. El archivo protege la información por medio de mecanismos técnicos y
procedimientos apropiados mientras están a su cargo. Si una disputa se da en una fecha
posterior, la información puede ser utilizada para verificar que la llave privada asociada con
el certificado fue utilizada para firmar un documento. Esto permite la verificación de firmas
en documentos antiguos, como por ejemplo testamentos, en una fecha posterior.
36
2.4.5. Entidades Finales: Usuarios y Dispositivos
El usuario o dispositivo es una hoja en el árbol de PKI, es una entidad final. Una entidad
final no puede emitir certificados hijos por lo que lo único que puede hacerse con el
certificado es utilizarlo para operaciones criptográficas que involucren a la entidad final
directamente. Algunos de los usos más populares incluyen la autenticación hacia un sistema
IT como VPN, servidor web, firma digital de correo electrónico y cifrado de contenido. [10]
El certificado digital es la identidad digital del usuario final, por lo que es crucial
protegerlo para evitar un posible robo de identidad. El certificado en sí es información
pública, sin embargo, el par de llaves asociado, la llave privada específicamente, es
información secreta, ya que es la utilizada para generar contenido criptográfico ligado al
certificado. La llave privada debe estar accesible para ser utilizada, sin embargo, debe ser
protegida ante copia o robo. En el sistema PKI más básico, el par de llaves podría ser
almacenado en un disco duro con protección de contraseña. En los modelos más elaborados
se utilizan dispositivos criptográficos más avanzadas, como tarjetas de circuitos integrados
para almacenar la llave privada.
37
3. Estándares internacionales para PKI
En general las Infraestructuras de Llave Pública son utilizadas en diversos dominios de
aplicación para implementar distintos casos de uso (certificados para sitios web, firmas
digitales, certificados de persona física, code signing, etc..). El éxito y el correcto
funcionamiento de una infraestructura de PKI depende del nivel de confianza que tengan
todos los actores entre sí, y en particular hacia la Autoridad Certificadora y sus prácticas de
certificación. La CA es el tercero de confianza, es el actor que sostiene la confiabilidad
completa del sistema. Por esta razón, desde los inicios de la utilización de Infraestructuras de
Llave Pública para la emisión de certificados para uso público, se han a desarrollado guías,
estándares y prácticas de aseguramiento para la evaluación de las prácticas, procedimientos
y procesos de la Autoridad Certificadora, los cuales poco a poco han sido estandarizados y
convertidos en normas y estándares internacionales aceptados por la industria [14]. Estos
estándares son los que se utilizan como punto de partida para la evaluación y auditoría de
Autoridades Certificadoras utilizadas para la emisión de certificados digitales en diversos
ámbitos, por ejemplo entidades financieras, organizaciones, empresas y la implementación
de infraestructuras de llave pública a nivel nacional como mecanismo de firma digital con
validez legal.
Uno de los objetivos principales de una PKI a nivel país es masificar su uso con el fin
de extender las ventajas de la Infraestructura a la mayor cantidad de ciudadanos del país (y
también obtener el mayor rédito de la inversión realizada a nivel gubernamental). En este
contexto de masificación es necesario tomar en cuenta que los certificados generados deben
facilitar su uso e integración dentro de las tareas cotidianas de los usuarios. Esto con el fin
de reducir la posible resistencia al cambio por parte de los usuarios, que naturalmente podrían
desconfiar de un sistema que les permite realizar acciones con valor legal sin un papel físico
de por medio (causado probablemente por un desconocimiento de los elementos técnicos que
garantizan su confiabilidad).
38
Los principales casos de uso de un usuario promedio dentro de un escenario de firma
digital involucra la autenticación y la firma de documentos. En ambos casos, el primer
elemento importante es la compatibilidad de los dispositivos y el software utilizados con el
sistema operativo. El segundo es con los exploradores web. Por ejemplo, un usuario podría
utilizar su certificado para ingresar a su cuenta de usuario en la máquina de su trabajo, y
luego solicitar una constancia de seguro o revisar su historial crediticia accediendo a los
portales provistos para alguna organización gubernamental.
Todos estos aspectos hacen que la escogencia y evaluación de los posibles estándares
para aplicar en el SNCD involucre un esfuerzo de investigación importante. Además de
analizar los estándares ya conocidos, también se deberían analizar aquellos relevantes desde
otras perspectivas, por ejemplo para incluir el certificado raíz de la CA Raíz en los principales
sistemas operativos y exploradores web. Además se hace necesario revisar la legislación,
prácticas y requisitos de otros países de la región, con el fin facilitar a futuro el proceso de
homologación de los certificados por ejemplo con otros países latinoamericanos o miembros
de la Organisation for Economic Co-operation and Development (OCDE) en un eventual
ingreso de Costa Rica.
El objetivo principal de este capítulo es seleccionar y caracterizar al menos tres
estándares internacionales utilizados para certificar Autoridades Certificadoras en el contexto
de una infraestructura de PKI. Inicialmente se presenta la metodología utilizada para la
selección de los estándares y los criterios de selección utilizados. Una vez seleccionados los
estándares, se describe para cada uno su historia, estructura y el proceso de certificación que
requiere cada uno de ellos.
3.1. Metodología
Debido a los distintos elementos que deben ser considerados cuando se implementa una
Infraestructura de Llave Pública, especialmente a nivel nacional, se diseñó un proceso para
39
la escogencia de los estándares que fueron utilizados en el resto de la investigación. La Figura
7 muestra el proceso utilizado.
Figura 7. Metodología utilizada para la selección de estándares.
Inicialmente se identificaron las normas y estándares utilizados a nivel mundial para la
evaluación de las prácticas de una Autoridad Certificadora. Para esto se realizaron las
siguientes actividades:
§ Revisión de la literatura y legislación vigente de modelos de implementación de PKI
a nivel país en distintos países del mundo.
§ Identificación de programas de certificación disponibles a nivel internacional.
§ Recopilación de los estándares, consorcios o acuerdos internacionales relacionados.
§ Análisis de los requisitos solicitados por los distintos sistemas operativos y
navegadores web para la inclusión de los certificados raíz de una Infraestructura de
PKI en sus repositorios de certificados.
Con la lista obtenida en el paso anterior, la siguiente etapa consistió en la identificación
de los siguientes elementos para cada uno de los estándares encontrados:
§ ¿Fue el estándar desarrollado para aplicaciones comerciales o para soluciones de
nivel país o regionales?
§ ¿Es el estándar aplicable solamente a Autoridades Certificadoras? ¿Incluye
Autoridades de Registro o algún otro elemento?
Identificacióndeestándares
RecopilacióndeInformación
Seleccióndelosestándares
40
§ ¿Es el ente creador del estándar un organismo internacional (ISO, IEEE, NIST), un
Gobierno, u otra organización?
§ ¿En cuántos y cuáles países se utiliza el estándar?
Con base en la información recopilada anteriormente, se procedió a seleccionar los
estándares que fueron utilizados para la investigación, utilizando los siguientes criterios:
§ Reconocimiento: Analizar el reconocimiento a nivel mundial y de la industria de cada
estándar, con base en su utilización, reputación y confianza.
§ Jerarquía: Se prefieren estándares que son base para otros estándares, es decir, entre
más arriba esté el estándar en una jerarquía de estándares relacionados, mejor.
§ Aceptación: Analizar el ámbito en el cuál cada estándar es aceptado y preferir
aquellos con niveles de aceptación mayores.
§ Aplicabilidad: Analizar para cada estándar el nivel de aplicabilidad para los objetivos
del proyecto, es decir, sean estándares relacionados a la implementación de
Autoridades Certificadoras en Infraestructuras de PKI, idealmente a nivel país.
Se presentan a continuación los resultados obtenidos luego de realizar las actividades
descritas anteriormente.
3.2. Estándares Seleccionados
El primer paso realizado fue un análisis de los requisitos solicitados por diversos países
a nivel mundial para la implementación de una Autoridad Certificadora dentro de su
Infraestructura de generación de Certificados Digitales a nivel país. Inicialmente se
analizaron los países de América Latina. Posteriormente se extendió el análisis a aquellos
países que son conocidos por su nivel avanzado de digitalización. Finalmente se analizaron
algunos países adicionales. En general se tomaron en cuenta los requisitos de los países en
los cuáles su documentación estuviera disponible en español, inglés, alemán o francés.
41
Para la mayoría de países, la reglamentación de su infraestructura de firma digital está
regulada por medio de leyes del país, con elementos adicionales definidos en decretos
ejecutivos o reglamentos. En la mayoría existe una dependencia de algún Ministerio de
Gobierno que es la encargada de la implementación y regulación de la Infraestructura de
Llave Pública del país.
A nivel centroamericano el modelo para la definición de los requisitos para implementar
una CA son diversos. En el caso de Costa Rica, el reglamento de la Ley de Firma Digital
establece que toda Autoridad Certificadora debe cumplir con los requisitos establecidos en
el estándar ISO-21188 Public key infrastructure for financial services [15], como se
mencionó anteriormente. En el caso de Honduras, existe un reglamento (referencia),
publicado en el año 2015, el cuál designa a la Dirección Nacional de Propiedad Intelectual
como la Autoridad Acreditadora, encargada de realizar las auditorías correspondientes con
base en los requisitos definidos por la ley, el reglamento y la misma Dirección. En Nicaragua,
la ley que regula la firma digital delega en la Dirección General de Tecnología adscrita al
Ministerio de Hacienda, el rol de Entidad Rectora de los requisitos para los proveedores de
servicios de certificación, los cuales no incluyen ningún estándar internacional. Para El
Salvador, la Ley que regula la firma electrónica entró en vigencia el 26 de abril del 2016,
mediante la creación de la Unidad de Firma Electrónica, adscrita al Ministerio de Economía.
Los requisitos para ser un proveedor de servicios de certificación no han sido publicados. En
Guatemala, el proceso de registro está mucho mejor definido. Para una Autoridad
Certificadora, se solicita al menos uno de los siguientes estándares: ISO/IEC 27001:2013
Information technology -- Security techniques -- Information security management systems -
- Requirements o Webtrust. La Tabla 4 muestra los resultados obtenidos al investigar los
requisitos de diversos países latinoamericanos y europeos.
Por otro lado, se realizó un proceso de revisión de los requisitos que cada sistema
operativo tiene para permitir la inclusión de la llave pública de una Autoridad Certificadora
en su repositorio de certificados. Cada sistema operativo tiene sus propios requisitos, como
42
se muestra en la Tabla 5. Sobresale de los resultados obtenidos Webtrust, el cual es aceptado
por MacOS y Windows.
Tabla 4. Estándares requeridos en los países de América Latina para la implementación de
Autoridades Certificadoras.
Elaboración Propia.
País Estándar Requerido Argentina Requisitos propios Bolivia Sin requisitos documentados. Brasil Estándar Propio. Canadá Webtrust Chile ETSI TS 102 Colombia Sin requisitos documentados. Costa Rica ISO-21188 Ecuador ETSI TS 102 El Salvador Sin requisitos documentados. Estados Unidos FCPCA / Webtrust / ETSI Guatemala ISO-27001 / Webtrust Haití Sin requisitos documentados. Honduras Requisitos propios Jamaica Sin requisitos documentados. México ETSI TS 102 Nicaragua Sin requisitos documentados. Panamá Por definir Paraguay Sin requisitos documentados. Perú ETSI TS 102 República Dominicana Sin requisitos documentados. Unión Europea ETSI EN 319 411 / ETSI TS 102 Uruguay Webtrust Venezuela ETSI TS 102
En el caso de Windows, este acepta tanto Webtrust, el estándar europeo ETSI TS 101 y
en caso de las Autoridades Certificadores de un país, se acepta una auditoría que indique que
cumplen con todos los requisitos legales necesarios a nivel del país. Sin embargo, en este
caso, la CA está limitada a emitir solamente certificados dentro de la jerarquía de la que es
dueña [16]. Es importante recalcar que hasta antes de Julio de 2015, Microsoft aceptaba el
43
ISO-21188. Sin embargo este fue removido con una actualización completa del programa de
certificados raíz publicada en Julio de 2015.
En el caso de iOS, Apple requiere que la CA disponga de una certificación Webtrust
[17] o alguna equivalente, pero hace la aclaración de que el peso de demostrar la
convalidación entre otro tipo de auditoría o certificación con respecto a Webtrust recae sobre
la CA solicitante. En el caso de Linux y Android, no existen programas específicos para
incluir certificados raíz. En el caso de Linux, el proceso sería complejo dada la gran cantidad
de distribuciones que existen. En el caso de Android, es algo que Google no ha implementado
hasta el momento.
Tabla 5. Estándares solicitados por sistemas operativos para incluir la llave pública de una CA
en su repositorio de certificados.
Sistema Operativo Requisito
Mac OS iOS
Webtrust o equivalente
Windows Webtrust
ETSI TS 101 / 102 Autoridad de Gobierno
Linux - Android Third-party trust
Posteriormente, se procedió a realizar una revisión de los requisitos impuestos por los
exploradores web más utilizados. Para esto se procedió a consultar las cuotas de mercado que
los exploradores más utilizados tienen. Existe un consenso en que los exploradores más
utilizados a nivel mundial son [18]:
• Google Chrome
• Mozilla Firefox
• Internet Explorer
• Safari
• Opera
44
Sin embargo, aunque no existe un consenso en el porcentaje que cada uno de estos
exploradores tiene en el mercado, lo relevante para esta investigación que es al seleccionar
los exploradores mencionados, se cubre en promedio un 95% de los usuarios de Internet. Por
esta razón, estos fueron los exploradores seleccionados.
Para cada uno de estos exploradores, se procedió a revisar los requisitos solicitados para
que una CA pueda tener su certificado raíz dentro del repositorio de certificados del
explorador. Los resultados obtenidos se muestran en la Tabla 6. En el caso de Chrome y
Opera, estos confían en las decisiones de aceptación tomadas por los administradores de la
librería Network Security Services, la cual es un conjunto de librerías publicadas por The
Mozilla Foundation para implementar aplicaciones que requieran elementos de seguridad en
múltiples plataformas [19]. En este caso, al ser un producto de Mozilla, los requisitos
solicitados son los mismos que para Firefox, el cual requiere que la CA presente una carta de
algún auditor adecuadamente acreditado indicando que la CA obtuvo la certificación de
Webtrust, versión 2.0 o más, ISO-21188:2006 o ETSI TS 102 042 V2.3.1, como se indica en
el Mozilla CA Certificate Inclusion Policy, versión 2.2 [20]. Es importante sin embargo
hacer notar que entre los comentarios realizados para la versión 2.3 de esta política, se incluye
la eliminación del estándar ISO-21188:2006 como una auditoría aceptada [21].
Por último de los requerimientos solicitados por Adobe, para su aplicación Adobe
Reader, herramienta que es generalmente utilizada para verificar y generar archivos firmados
digitalmente en formato PDF. Adobe requiere que una CA comercial presente una auditoría
realizada con Webtrust para CA, ETSI 101 456, ETSI 102 042, ISO 21188:2006 o la ley
alemana para auditorías de firmas digitales. Para CA gubernamentales se solicita cualquier
de las auditorías anteriores o alguna equivalente. [22]. En el caso de Internet Explorer (IE)
y Safari, estas comparten los requisitos solicitados para Windows y Mac OS/iOS
respectivamente. Para Internet Explorer, ETSI TS 101 / 102 o Webtrust y para Safari Webtrust
o equivalente.
45
Tabla 6. Estándares requeridos por exploradores web y Adobe.
Browser / Aplicación Requisito Chrome NSS by Mozilla Safari Webtrust o equivalente
Internet Explorer Webtrust
ETSI TS 101 / 102
NSS / Firefox / Adobe Webtrust
ETSI TS 101 / 102 ISO 21188*
Opera NSS by Mozilla
Después de analizar los requisitos tanto a nivel latinoamericano y europeo, a nivel de
sistemas operativos y a nivel de exploradores, resaltan los siguientes elementos:
• El estándar Webtrust es aceptado por todos los sistemas operativos que tienen un plan
definido para la aceptación de certificados raíz de una Autoridad Certificadora.
Además, entre ellos (Windows y Mac OS) acaparan el 95% aproximadamente de las
máquinas que corren en el mundo [18].
• El ISO-21188 era aceptado por Windows hasta mediados del 2015, además es
actualmente aceptado por Mozilla, pero será removido en la próxima versión de su
política de inclusión de certificados. Costa Rica es el único país que incluye
explícitamente el ISO-21188 como requisito para la implementación de una
Autoridad Certificadora a nivel nacional.
• A nivel de los países consultados, existe una marcada tendencia a no solicitar
explícitamente ningún estándar como parte de los requisitos.
• Dentro de los países que si tienen explícitamente un estándar hay una marcada
tendencia a aceptar el estándar norteamericano Webtrust o el estándar europeo ETSI
TS 102 042.
A partir de los resultados anteriores, se seleccionaron los siguientes estándares para esta
investigación:
46
§ ISO 21188:2006 Public key infrastructure for financial services -- Practices and
policy framework:
o Utilizado en Costa Rica.
o Desarrollado por la Organización de Estandarización Internacional (ISO)
organismo reconocido a nivel mundial.
o Es aceptado por algunos exploradores.
§ Trust Service Principles and Criteria for Certification Authorities Version 2.0 –
Webtrust:
o Utilizado en USA, Uruguay, Guatemala, Canadá.
o Aceptado por sistemas operativos y browsers.
o Desarrollado por la Asociación de Contadores Públicos de los Estados
Unidos.
§ ETSI TS 102 042 V2.3.1: Electronic Signatures and Infrastructures (ESI): Policy
requirements for certification authorities issuing public key certificates:
o Utilizado en la Unión Europea, México, Chile, Venezuela, Uruguay.
o Aceptado por sistemas operativos y browsers.
o Desarrollado por el European Telecommunications Standards Institute.
A continuación se describe cada uno de estos estándares, presentando su alcance,
historia y estructura.
3.3. ISO-21188: Public key infrastructure for financial services
La norma ISO 21188:2006 Public key infrastructure for financial services -- Practices
and policy framework es una norma preparada por el Comité Técnico ISO/TC 68, Servicios
47
Financieros. La norma fue desarrollada por el subcomité SC2, Gestión de la seguridad y
operaciones bancarias generales de la Organización Internacional de Normalización (ISO).
La norma define una serie de objetivos y procedimientos de control para la implementación
de infraestructuras de llave pública en entidades financieras. En adelante, por facilidad, se
referirá a esta norma como ISO-21188.
El ISO-21188 define un conjunto de requerimientos para manejar una infraestructura de
llave pública a través de políticas de certificados y declaraciones de prácticas de certificación,
como se define en el RFC3647 Certificate Policy and Certification Practices Framework
[23], esto con el fin de permitir el uso de certificados de llave pública en entidades dentro de
la industria financiera.
El propósito principal de la norma es definir una serie de objetivos de control y posibles
mecanismos de control con el fin de administrar los riesgos a los que están expuestos los
distintos actores de una infraestructura de llave pública, especialmente en el caso de la
Autoridad Certificadora, componente clave de la confianza general del sistema.
Originalmente, la norma se diseñó con el fin de proporcionar una base de lineamientos
que se pudieran seguir para poder evaluar el nivel de aseguramiento y confianza de una
infraestructura de llave pública desarrollada en ambientes financieros. Inicialmente, las
entidades financieras eran las organizaciones que utilizaban certificados de llave pública para
proveer servicios con un nivel de confianza elevado, dada lo sensible de las operaciones y
activos que manejan.
La norma describe 3 escenarios distintos en los cuáles una entidad financiera puede
utilizar una infraestructura de llave pública, según su relación con las partes que confían:
§ Ambiente cerrado: En este escenario todas los actores (sujetos poseedores de
certificado, el emisor del certificado y las partes que confían) se adhieren a un único
servicio de confianza de una institución financiera, y deben compartir al menos una
48
política de certificado. La Tabla 7 muestra algunos ejemplos de casos de usos en un
ambiente cerrado.
§ Ambiente contractual: En este escenario los sujetos de certificado y las partes que
confían pueden tener proveedores de servicios de confianza separados. En este caso,
cada proveedor (autoridad certificadora) está vinculado con los demás mediante
contratos previamente firmados que cubren el alcance del uso y la validación de
certificados. Estos contratos pueden ser tener distintas esquemas:
o Multilateral: todos los proveedores funcionan bajo una misma política de
certificado.
o Certificación cruzada bilateral: Cada proveedor puede utilizar diferentes
políticas de certificado.
o Acreditación: se pueden reconocer diferentes políticas de certificado a través
de una organización o entidad central.
§ Ambiente abierto: En este caso, la institución financiera puede actuar como un
proveedor de servicios de confianza que emite certificados al público y permite la
validación de certificados en un ambiente de red abierto. Los proveedores pueden
operar bajo esquemas de acreditación voluntarios o dentro de un marco regulatorio
autóctono. La característica principal de este escenario es que no hay ningún contrato
formal entre el proveedor de servicios y la parte que confía.
3.3.1. Estructura
El ISO-21188 está compuesto de 8 secciones. Las primeras 5 sirven como introducción
para la norma ya que describe el objeto y campo de aplicación, las normas de referencia,
términos y definiciones, abreviaturas de términos y finalmente brinda un repaso de los
principales conceptos de una Infraestructura de PKI.
49
Tabla 7. Escenarios de aplicación de certificados en un ambiente cerrado.
Tomada de [15].
Escenarios típicos Ejemplos de requisitos Operaciones PKI
1
La institución financiera envía un correo electrónico a un cliente (por ejemplo, la notificación de cambio en la tasa de depósitos).
• Autenticación del remitente por parte del destinatario.
• Integridad del mensaje para el remitente y destinatario
• El remitente crea una firma digital.
• El destinatario valida el certificado del remitente.
• El destinatario verifica la firma digital.
2
Intercambio de correos electrónicos sensibles entre empleados que están dentro de los límites de la red de la institución financiera.
• Autenticación del remitente por parte del destinatario.
• Integridad del
mensaje para el remitente y destinatario.
• Protección de confidencialidad para el contenido del mensaje.
• El destinatario valida el certificado del remitente.
• El remitente crea una firma digital.
• El destinatario verifica la firma digital.
• El remitente recupera el certificado del destinatario del directorio.
• El remitente encripta el mensaje con la llave pública del destinatario.
• El destinatario desencripta el mensaje con su llave privada.
3
Fuerza de ventas viajera con computadores portátiles de la institución financiera que necesita intercambiar información de clientes y ventas con los sistemas de apoyo centralizados.
• Autenticación mutua del empleado por parte de la institución financiera y del servidor por parte del empleado.
• Protección de confidencialidad para los datos.
• Suministro de certificados de identificación de empleados.
• Suministro de certificado de identificación de servidor.
• Invocar la encripción SSL.
4
Red de distribución interna del software de la institución financiera hacia los dispositivos orientados al cliente (por ejemplo: software ATM “Automatic Teller Machine”).
• Probar que el software que está siendo cargado en los dispositivos proviene de una fuente auténtica.
• La institución financiera firma digitalmente las aplicaciones de software.
• El destinatario verifica la firma digital.
• El destinatario valida el certificado de la institución financiera.
5
Cliente utilizando un servicio bancario remoto donde el servidor y la aplicación de navegación son suministrados por la institución financiera.
• Autenticación mutua del cliente por parte de la institución financiera y del servidor por parte del software cliente.
• El cliente se autentica con el servicio utilizando el certificado de cliente.
• El servidor se autentica con el cliente utilizando el certificado de servidor.
50
La sección 6 describe los requisitos que debe cumplir la Política de Certificados de la
Infraestructura así como la Declaración de Prácticas de Certificación de cada CA de la
Infraestructura. Es importante recalcar que este estándar no está específicamente diseñado
para la auditoría de Autoridades Certificadoras (aunque la mayor parte de su contenido está
enfocado en esto), sino más bien como una norma para infraestructuras de llave pública en
general. La sección 7 de la norma presenta los objetivos de control que una Autoridad
Certificadora debe tomar en cuenta para una auditoría. La Tabla 8 muestra las categorías en
que está divididos los objetivos de control, así como los elementos dentro de cada categoría
que deben ser evaluados. Finalmente la sección 8 de la norma presenta una lista de
mecanismos de control para cada uno de los objetivos de control que pueden ser utilizados
de guía para el auditor encargado de realizar revisiones en una Autoridad Certificadora.
3.3.2. Proceso de Evaluación
La norma ISO 21188:2006 Public key infrastructure for financial services -- Practices
and policy framework es una norma que se puede utilizar para realizar procesos de evaluación
y de auditoría. Sin embargo, realizar auditorías con respecto a esta norma no es algo común
[14] [24]. En un proceso de evaluación, una organización puede utilizar la norma para realizar
diagnósticos del estado actual de los objetivos y mecanismos de control con el fin de
prepararse para un proceso de auditoría. El resultado de un proceso de evaluación es una lista
de elementos por mejorar. Un proceso de auditoría o certificación es un proceso formal
realizado por un tercero imparcial, que con base en una norma o estándar previamente
definido Este tercero emite un criterio ya sea positivo o negativo de conformación de los
requisitos de la norma con base en la revisión de procesos y recolección de evidencias. [14]
51
Tabla 8. Estructura de los objetivos de control especificados en el ISO 21188. Compilado a partir de [15].
Sección de la norma Elementos evaluados en la sección
CA environmental control objectives
1. Certification practice statement and certificate policy management
2. Security management 3. Asset classification and management 4. Personnel security 5. Physical and environmental security 6. Operations management 7. System access management 8. Systems development and maintenance 9. Business continuity management 10. Monitoring and compliance 11. Audit logging
CA key life cycle
management control objectives
1. CA key generation 2. CA key storage, back-up and recovery 3. CA public key distribution 4. CA key usage 5. CA key archival and destruction 6. CA key compromise
Subject key life cycle management control
objectives
1. CA-provided subject key generation services (if supported) 2. CA-provided subject key storage, recovery and escrow
services (if supported) 3. Integrated circuit card (ICC) life cycle management (if
supported) 4. Requirements for subject key management
Certificate life cycle management control
objectives
1. Subject registration 2. Certificate renewal (if supported) 3. Certificate re-key 4. Certificate issuance 5. Certificate distribution 6. Certificate revocation 7. Certificate suspension (if supported) 8. Certificate validation services
CA certificate life cycle management controls
1. Subordinate CA certificate life cycle management
52
Las normas emitidas por la ISO se clasifican según su contenido, por ejemplo, la ISO
establece su documentación técnica en Normas Internacionales (IS), Especificaciones
Técnicas (TS), Especificaciones Disponibles al Público (PAS), Informes Técnicos (TR),
Guías (elaboradas el Comité de Políticas COPOLCO) y Acuerdos Internacionales obtenidos
en Talleres de Trabajo (IWA). Dentro de las normas internacionales existe una gran variedad,
como son las normas de requisitos que son las únicas certificables, normas de directrices,
lineamientos, definiciones y otras. La norma ISO-21188 define una serie de directrices y
lineamientos para la implementación de Autoridades Certificados, por ende no es
certificable.
El estándar ISO-21188, siendo una norma internacional, puede ser evaluada o auditada
por un experto comprobando los requisitos que define. Como es normal en las normas de la
ISO, los elementos necesarios para cumplir con la norma están divididos en 2 grupos: los
requisitos que son obligatorios (must) y los que son deseables (should). El mismo estándar
indica que para cumplir con la norma internacional se tiene que cumplir con todos los
objetivos de control que son obligatorios. Los siguientes objetivos son los únicos que son
considerados opcionales, ya que aplican solamente si son soportados por la CA:
1. Servicios de generación de llaves de sujeto provistos por la CA;
2. Servicios de custodia, almacenamiento y recuperación de llaves de sujeto provistos
por la CA;
3. Gestión del ciclo de vida de las Tarjetas de Circuito Integrado (ICC);
4. Renovación de certificados;
5. Suspensión de certificados.
En Costa Rica solamente aplican la gestión del ciclo de vida de las tarjetas y la
suspensión de certificados con base en la última versión del CP. En el caso de los
procedimientos de control, la norma indica que son requeridos todos aquellos que están
especificados como “debe” en vez de “debería”. Cabe destacar que mayoría de los
procedimientos de control están definidos como deberían.
53
El ISO-21188 al ser una norma aprobada de la ISO ha sido adoptada por la mayoría de
países. Esta es generalmente utilizada como base para la generación de estándares o guías de
auditoría a nivel nacional, regional o internacional, por ejemplo los principios y criterios
definidos para el programa Webtrust.
3.4. Trust Service Principles and Criteria for Certification
Authorities
El Trust Service Principles and Criteria for Certification Authorities [25] es un estándar
desarrollado en conjunto por el Canadian Institute of Chartered Accountants (CICA) y el
American Institute of Certified Public Accountants (AICPA). Este estándar define una serie
de principios y criterios para la implementación de una Autoridad Certificadora. El
cumplimiento del estándar es un requisito necesario para aprobar una auditoría del programa
Webtrust para Autoridades Certificadora del AICPA/CICA.
La última versión oficial del estándar es la 2.0. Esta versión, publicada en el año 2011,
reemplazó la versión anterior 1.0. La versión 2.0 fue desarrollada por un Comité formado por
profesionales de ambas instituciones utilizando como base el estándar ISO 21188:2006
Public key infrastructure for financial services -- Practices and policy framework y la versión
1.0.
3.4.1. Relación entre ISO-21188 y Webtrust
El uso de infraestructuras de llave pública adquirió relevancia a mediados de la década
de los 90 debido al auge del comercio electrónico ocasionado por la universalización del
acceso a Internet. Durante ese período ya existían programas de auditoría para diversos tipos
de sistemas. En los Estados Unidos, estos programas son generalmente manejado por el
AICPA. Las auditorías para sistemas informáticos y para Autoridades Certificadoras se
realizaban bajo el programa Statement on Auditing Standards (SAS) No. 70, auditorías para
organizaciones que prestan servicios [14]. Este programa sin embargo, no definía criterios
54
de evaluación, solamente proveía la metodología para brindar un reporte sobre las prácticas
de la organización. La auditoría en sí de la implementación de la Autoridad Certificadora se
realizaba con otro experto en el tema, cuyos resultados eran asumidos como correctos por los
auditores de SAS 70.
El Accredited Standards Committee X9, generalmente conocido como ASC X9 o X9, es
una organizada dedicada al desarrollo de estándares para servicios financieros aprobada por
la American National Standards Institute (ANSI). X9 es el USA Technical Advisory Group
(TAG) ante el International Technical Committee on Financial Services ISO/TC 68, un
comité de la Organization for Standardization (ISO). Como representante ante la ISO, X9
es la organización encargada de proponer los estándares desarrollados en los Estados Unidos
al Comité Internacional para que se considerados para adopción a nivel internacional. X9
está conformado por 5 comités:
§ X9AB - Pagos § X9C - Créditos § X9D - Valores § X9F – Datos y Seguridad de la Información
En diciembre de 1997, el X9 estableció un nuevo grupo de trabajo, el X9F5, con el
objetivo de desarrollar un conjunto de políticas y prácticas para la implementación de
infraestructuras de llave pública en la industria de servicios financieros. Este estándar fue
publicado en 2001 y se llamó X9.79. Durante el proceso de trabajo del X9F5, se publicaron
las especificaciones de IETF para la definición de una política de certificados y de una
declaración de prácticas de certificación (RFC 2527 [26], luego reemplazado por RFC 3647
[23]). Durante el mismo período, la AICPA estaba desarrollando una guía para auditar
Autoridades Certificadoras como parte de su programa Webtrust. AICPA/CICA WebTrust
Program for Certification Authorities, Version 1.0 fue publicado en agosto del 2000,
tomando elementos del estándar X9.79, que fue publicado en enero del 2001. [14]
El estándar X9.79 fue enviado a la ISO como una propuesta de los Estados Unidos para
el desarrollo de un estándar internacional para PKI. Este estándar fue desarrollado por el
Comité Técnico ISO/TC 68, Servicios Financieros y en específico el subcomité SC2, Gestión
55
de la seguridad y operaciones bancarias generales de la (ISO). El estándar fue publicado en
mayo de 2006 como ISO 21188 Public Key Infrastructure for Financial Services—Practices
and Policy Framework. [14]
Durante el período en el que la ISO estaba trabajando en el desarrollo del estándar, la
industria y en específico Apple, Google, Microsoft y Mozilla adoptaron Webtrust 1.0 como
auditoría necesaria para la incorporación de los certificados raíz de una CA en sus distintas
plataformas [14]. Webtrust 1.0, al publicarse 6 meses antes que el X9.79 y sobretodo, 6 años
antes que el ISO-21188, difería en estructura, procedimientos y objetivos de control
incorporados durante el proceso de trabajo del grupo de la ISO. Con el ISO-21188 aprobado
y publicado, en 2008 el estándar X9.79 fue retirado y los Estados Unidos adoptó el estándar
internacional como norma. En 2011 la AICPA publicó una nueva versión (2.0) incorporando
todos los cambios y siguiendo la estructura del ISO-21188. A partir de esta nueva versión,
las compañías antes mencionadas requieren ahora una auditoría aprobada de la versión 2.0.
La Figura 8 muestra la evolución de los distintos estándares desde la década de los 90 hasta
la actualidad.
3.4.2. Estructura
El estándar Webtrust tiene una estructura similar a la descrita para la norma ISO-21188.
Inicialmente describe el alcance del documento y explica brevemente los principales
conceptos de PKI. A diferencia de ISO-21188, este presenta los criterios (objetivos de
control) y los controles (procedimientos de control) que se deben verificar al evaluar o auditar
una CA utilizando Webtrust en la misma sección y no por separado como en el ISO-21188
(cada sección de Webtrust es similar a la sección correspondiente en el capítulo 8 de la
norma). La Tabla 9 muestra las secciones en las que se divide el documento. Se puede
observar que existe una correspondencia casi exacta entre los elementos definidos para la
norma y los elementos definidos en Webtrust.
56
Figura 8. Evolución de los estándares para certificación y auditoria de Autoridades Certificadoras.
Tomado de [14].
57
3.4.3. Proceso de evaluación y auditoría
La lista completa de criterios y procedimientos de control utilizados para realizar una
auditoría del programa WebTrust para CA está disponible de forma gratuita en la página de
programa. Esta puede utilizarse para realizar evaluaciones diagnósticas en preparación para
una auditoría. Una auditoría si es un proceso formal que debe realizarse con una organización
acreditada para realizarla por AICPA. La lista oficial se puede consultar en la página de
Webtrust (http://bit.ly/29eJGFp).
En general una auditoría de WebTrust tiene un costo más alto que el costo promedio de
una auditoría de seguridad informática. Por ejemplo una auditoría para ISO-27001 puede
costar hastsa $70.000 [27], mientras que el costo de una auditoría de Webtrust está entre los
$50.000 y los $250.000 [28]. Esto se debe al nivel de especialización requerido por los
auditores y por la cantidad de procesos, evaluaciones y evidencia que se debe recolectar.
Depende también de la complejidad del ambiente que se debe auditar, incluyendo el número
de Autoridades Certificadoras, el tamaño de la jerarquía, entre otros. Una vez que la CA ha
superado la auditoría, puede hacer uso de los sellos correspondientes del Programa Webtrust
en su página web y documentación.
3.5. ETSI TS 102 042
El estándar ETSI TS 102 042 Policy requirements for certification authorities issuing
public key certificates es un estándar desarrollado por el European Telecommunications
Standards Institute (ETSI). Este instituto es una organización sin fines de lucro que fue creada
en 1988 para ayudar a estandarizar diversos elementos del espectro tecnológico europeo. Es
un organismo reconocido por la Unión Europea (EU por sus siglas en inglés), y sus estándares
deben tener la aprobación de los 28 miembros de la misma para su puesta en práctica en todos
los países miembros de la EU.
58
Tabla 9. Estructura de los contenidos de Webtrust.
Section Webtrust Objetivos de Control
CA Business Practices Disclosure
1. Certification Practice Statement (CPS) 2. Certificate Policy (if applicable)
CA Business Practices Management
1. Certificate Policy Management (if applicable) 2. Certification Practice Statement Management 3. CP and CPS Consistency (if applicable)
CA Environmental Controls
1. Security Management 2. Asset Classification and Management 3. Personnel Security 4. Physical and Environmental Security 5. Operations Management 6. System Access Management 7. Systems Development and Maintenance 8. Business Continuity Management 9. Monitoring and Compliance 10. Audit Logging
CA Key Life Cycle Management Controls
1. CA Key Generation 2. CA Key Storage, Backup and Recovery 3. CA Public Key Distribution 4. CA Key Usage 5. CA Key Archival and Destruction 6. CA Key Compromise 7. CA Cryptographic Hardware Life Cycle Management 8. CA Key Escrow (if applicable)
Subscriber Key Life Cycle Management
Controls
1. CA-Provided Subscriber Key Generation Services (if supported) 2. CA-Provided Subscriber Key Storage and Recovery Services (if
supported) 3. Integrated Circuit Card (ICC) Life Cycle Management (if
supported) 4. Requirements for Subscriber Key Management
Certificate Life Cycle Management Controls
1. Subscriber Registration 2. Certificate Renewal (if supported) 3. Certificate Rekey 4. Certificate Issuance 5. Certificate Distribution 6. Certificate Revocation 7. Certificate Suspension (if supported) 8. Certificate Validation
Subordinate CA Certificate Life Cycle Management Controls
1. Subordinate CA Certificate Life Cycle Management
59
En la Unión Europea las firmas electrónicas fueron normadas inicialmente mediante la
Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999
on a Community framework for electronic signatures [29]. El elemento principal de esta
directiva es el artículo 5:
Artículo 5. Efectos Legales de las firmas electrónicas Los estados miembros se deben asegurarse que las firmas electrónicas avanzadas que son creadas con base en un certificada calificado y que son creados utilizando un dispositivo seguro para la creación de la firma: 1. Satisfacen los requisitos legales de una firma en relación con los datos en forma
electrónica de la misma manera que una firma escrita satisfice los requisitos en
relación con documentos en papel.
2. Son admisibles como evidencia en procesos legales.
Para estandarizar la implementación de certificados digitales y la infraestructura de llave
pública a nivel europeo, el ETSI desarrolló una serie de estándares para definir los requisitos
necesarios para la implementación de Autoridades Certificadoras, entre ellos:
§ ETSI TS 102 042: Electronic Signatures and Infrastructures (ESI): Policy
requirements for certification authorities issuing public key certificates.
§ ETSI TS 102 158: "Electronic Signatures and Infrastructures (ESI); Policy
requirements for Certification Service Providers issuing attribute
certificates usable with Qualified certificates".
§ ETSI TS 101 456: "Electronic Signatures and Infrastructures (ESI); Policy
requirements for certification authorities issuing qualified certificates".
Estos estándares son los que se mencionaron como requisitos en la industria para sistemas
operativos y exploradores web al inicio de este capítulo.
En 2013 ETSI desarrolló la familia de estándares ETSI EN 319 411 Electronic
Signatures and Infrastructures (ESI), Policy and security requirements for Trust Service
Providers issuing certificates::
60
§ ETSI EN 319 411-1 Part 1: General requirements
§ ETSI EN 319 411-2 Part 2: Requirements for trust service providers issuing
EU qualified certificates.
§ ETSI EN 319 411-3: Part 3: Policy Requirements for Certification Authorities
issuing public key certificates.
La idea era que estos estándares sustituyeran a la vieja familia de estándares TS 101/102
[30]. Sin embargo, en 2014 la Unión Europea introdujo una nueva directiva, “REGULATION
(EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23
July 2014 on electronic identification and trust services for electronic transactions in the
internal market” conocida como eIDAS, la cual reemplazó la Directiva anterior y definió
una nueva serie de requisitos y clases de certificados con base en la utilización y su valor
legal. El problema es que los estándares diseñados en 2013 (familia 319 411) no seguían los
lineamientos definidos en la nueva legislación, por lo cual durante los años del 2013 al 2016,
se contó con dos familias diferentes de estándares. Por esta razón, misma ETSI recomendaba
utilizar la familia anterior (101/102) mientras se generaba una nueva versión de la familia
319 conforme a los lineamientos de la legislación de eIDAS [30]. Es por esta razón que los
principales sistemas operativos y exploradores todavía aceptan la familia 101/102 [31] [16]
[21] como auditoría para la inclusión de certificados en su repositorio, a pesar de ser la familia
más antigua de estándares desarrollados a nivel europeo.
La nueva familia de estándares se desarrolló durante el 2015 y 2016. Este tomó en cuenta
las dos familias anteriores para generar una serie de estándares más simples de aplicar y
siguiendo los lineamientos de la nueva legislación. Durante este período la publicación de
versiones en borrador de los estándares nuevos fue esporádica y no centralizada.
Las nuevas versiones de los estándares entraron en vigencia el 1 de Julio de 2016 y
siguen la siguiente jerarquía [32]:
§ TR 119 400 v1.1.1 on Guidance on the use of standards for trust service providers supporting digital signatures and related services
§ EN 319 403 v2.2.2: Requirements for conformity assessment bodies assessing Trust
61
Service Providers § EN 319 401 v2.1.1 General Policy Requirements for Trust Service Providers
§ EN 319 411 Policy and security requirements for Trust Service Providers issuing certificates
o 319 411-1 v1.1.1: General requirements o 319 411-2 v2.1.1: Requirements for trust service providers issuing EU qualified
certificates § EN 319 421 v1.1.1: Policy and Security Requirements for Trust Service Providers
issuing Electronic Time-Stamps § EN 319 412 Certificate Profiles
o 319 412-1 v1.1.1: Overview and common data structures o 319 412-2 v2.1.1: Certificate profile for certificates issued to natural persons
o 319 412-3 v1.1.1: Certificate profile for certificates issued to legal persons o 319 412-4 v1.1.1: Certificate profile for web site certificates issued to
organisations o 319 412-5 v2.1.1: QCStatements
§ EN 319 422 v1.1.1 Time-stamping protocol and electronic time-stamp profiles
Debido al período de transición en que se hayan los estándares a nivel de la Unión Europea,
se decidió no utilizar los estándares de la vieja familia 101/102 para este proyecto de
investigación. Ya que estos aparte de ser la familia más antigua, se volvieron obsoletos en
Julio de 2016. De igual forma, se decidió no analizar la familia intermedia de (319 411) ya
que esta tampoco responde a la nueva legislación de la Unión Europea, por lo que al ser
descartados durante este año, no es probable que se deseen usar como estándar en Costa Rica.
En el momento de redactar este documento, la versión final de los estándares
anteriormente mencionados no había sido publicada. Por esta razón, la evaluación de la
aplicabilidad del nuevo estándar definido en la Unión Europea no se pudo realizar. No
obstante, el proceso realizado de investigación y recolección de los elementos explicados
anteriormente son en sí mismos un avance muy importante, pues permiten evaluar los nuevos
estándares y la evolución que los estándares de firma digital están teniendo en la Unión
Europea, ya que la nueva legislación se aprobó con el objetivo de masificar el uso de la firma
62
digital. La nueva familia de estándares busca estandarizar el proceso de evaluación y
auditorías, utilizando normas internacionales vigentes. Ambos objetivos están siendo
perseguidos en Costa Rica también. El análisis de los nuevos estándares será realizado
posteriormente como parte del proyecto de investigación que se está realizando en la ECCI-
CITIC.
3.6. Resumen
Durante el proceso de selección de los estándares por analizar se encontraron varios
elementos interesantes:
1. El proceso de selección de los estándares por evaluar involucró la investigación de
los requisitos necesarios para implementar una CA dentro de la Jerarquía Nacional
de Certificadores Registrados para diversos países de América Latina y otros.
2. La mayoría de los países mantiene la autonomía con respecto a la revisión de las
capacidades de las autoridades certificadoras de su jerarquía. Las razones para esto
sería interesante estudiarlas más a fondo en el futuro, ya que se puede conjeturar que
puede ser por cuestiones económicas, desconocimiento o madurez del proceso de
implementación de la Infraestructura de Llave Pública o por requisitos especiales que
tengan que tener las CA registradas.
3. Entre los países que fueron analizados y que si definen un estándar para una
infraestructura de llave pública a nivel país, Webtrust y los estándares de la Unión
Europea (familia TS 101/102) son los más utilizados. El ISO-21188 solamente se
utiliza en Costa Rica.
4. Se revisaron también los requisitos necesarios para poder tener el certificado raíz de
una CA en los distintos repositorios de llaves para los principales sistemas operativos
y browsers. Para estos, los estándares aceptados también son Webtrust, la familia TS
63
101/102 de la Unión Europea, la norma ISO-21188. Aunque este último dejará de ser
aceptado en el corto plazo tanto por Microsoft como por Mozilla.
5. El ISO-21188 es una norma internacional no certificable, que puede ser la base para
una auditoría para la evaluación de los procedimientos de una Autoridad
Certificadora.
6. La última versión de Webtrust fue diseñado con base en la norma ISO-21188, por lo
que la estructura y los objetivos de control contenidos en la norma están en la versión
2.0 de Webtrust.
7. Webtrust contiene una serie de elementos adicionales, no presentes en el ISO-21188,
que deberían ser analizados si se quisiera utilizar Webtrust a nivel nacional.
8. A nivel europeo, los estándares para la auditoría de Autoridades Certificadoras se
encuentran en un proceso de transición por la entrada en vigencia de la nueva
legislación de firma digital eIDAS, aprobada en el 2014. En los últimos 3 años, se ha
venido utilizando la vieja familia de estándares TS 101/102, a pesar de que una nueva
familia había sido diseñada. Con la nueva legislación, los nuevos estándares fueron
publicados y entraron en vigencia el 1 de Julio de 2016, a partir de esta fecha los
estándares anteriores son obsoletos. Por esta razón en este trabajo no se realizará el
análisis de la familia de estándares europeos, ya que durante el desarrollo del trabajo
no se tenía disposición la versión final de los nuevos estándares.
64
4. Identificación de requisitos nacionales
En este capítulo se presenta el proceso realizado para la identificación de los requisitos
que actualmente una Autoridad Certificadora tiene que cumplir para operar de forma legal
en Costa Rica. Inicialmente se describe la problemática existente y las razones por las cuáles
esta lista de requisitos no se puede obtener de forma sencilla. En segundo lugar se describe
el proceso utilizado para la identificación de los requisitos y por último se describen los
requisitos finalmente identificados.
4.1. Problemática existente.
Aunque actualmente existe sólo una CA en Costa Rica (CA-SINPE) del Banco Central
de Costa Rica, la ley permite la existencia de múltiples autoridades certificadoras, tanto
públicas como privadas que deben coexistir siguiendo la reglamentación, políticas, políticas
de certificado y demás requisitos establecidos por la DCFD. Al iniciar este trabajo de
investigación aplicada, cuando se estaba diseñando el proceso de evaluación de la
aplicabilidad de los estándares seleccionados, se empezó un proceso de revisión con el fin de
obtener los requisitos actuales para una CA en Costa Rica.
En las reuniones iniciales realizadas con el MICITT, el Banco Central y el Ente
Costarricense de Acreditación (ECA), se tocó este tema, al discutirse los posibles alcances
del trabajo, y cuando se hablaba de los requisitos para implementar una CA en Costa Rica
generalmente la respuesta era: la norma ISO-21188. Sin embargo, después de un proceso de
revisión de la normativa vigente se identificaron otros documentos que también definen
requisitos. Por ejemplo, es claro que toda CA en Costa Rica tiene que estar sometida a las
leyes de la República, por lo que la ley 8454 y el reglamento también podían contener
requisitos. En general, el problema existente es que no hay una lista concisa, clara y
disponible de todos los requisitos que una CA debe implementar.
65
En este proceso de revisión se identificaron varias situaciones que hizo que el proceso
de identificación de estos requisitos fuera una de las tareas más complejas de realizar. Entre
las situaciones encontradas destacan:
1. El Reglamento a la Ley 8454 define el ISO 17021: “Requirements for bodies
providing audit and certification of management systems” como un estándar
requerido por una CA en Costa Rica, pero este aún no ha sido implementado en las
Autoridades Certificadoras del SNCD.
2. La Política de Certificados publicada por la DCFD define una gran cantidad de
requisitos para una CA en Costa Rica, algunos de los cuáles son elementos de la
norma ISO-21188, pero muchos otros fueron agregados con base en el aporte de
diversos actores nacionales durante el desarrollo inicial del proyecto de firma digital.
3. En el reglamento a la Ley 8454, se solicita que la CA obtenga una acreditación del
ECA “de conformidad con los lineamientos técnicos establecidos en las Normas
INTE-ISO/IEC 17021 e INTE/ISO 21188 versión vigente, las políticas fijadas por la
DCFD y los restantes requisitos que esa dependencia establezca, de acuerdo con su
normativa específica”, lo cual presenta un problema de factibilidad. En primera
instancia las normas de estandarización se certifican o auditan, no se acreditan3 y el
ECA es un ente acreditador de organismos certificadores. Por esta razón actualmente
las CA del SNCD están imposibilitadas de cumplir con este requisito.
4. La norma ISO-21188, como se explicó en el capítulo anterior, define una serie de
objetivos de control, sin embargo estos están divididos en obligatorios y opcionales
3 El término acreditación es utilizado en el campo de la gestión de calidad para referirse a la condición que tiene un ente para poder auditar o certificar a un tercero con respecto a una norma o conjunto de requisitos previamente definidos. En este caso, el organismo que certifica una norma tiene que estar acreditado previamente. En Costa Rica esta acreditación debe ser realizada por el ECA según la Ley del Sistema Nacional de Calidad [40].
66
(must y should en la terminología del estándar), sin que exista una definición clara de
cuáles son necesarios y cuáles opcionales para Costa Rica.
5. La misma norma además está enfocada en el sector financiero y cubre varios aspectos
de una Infraestructura de PKI, no sólo de las Autoridades Certificadoras. Además no
menciona nada acerca de la implementación de infraestructuras de llave pública en
implementaciones a nivel nacional.
6. La DCFD desarrolló una guía de elementos que se revisan durante las visitas o
auditorías realizadas para la aprobación o no de una CA.
En resumen, al realizarse la pregunta de ¿Cuáles son los requisitos especificados en la
legislación costarricense actual que se le solicitan a una entidad que desee ser una Autoridad
Certificadora registrada en Costa Rica? La respuesta es compleja y actualmente no existe una
lista unificada, de fácil consulta y que permita la fácil verificación por parte de la DCFD de
los requisitos que una Autoridad Certificado tiene que cumplir para operar legalmente.
Para iniciar el proceso de identificación de los requisitos se realizó un proceso de
revisión de las leyes y reglamentos vigentes y de las políticas vigentes de la DCFD. También
se realizaron grupos de trabajo con la DCFD y organizaciones vinculados con el Sistema
Nacional de Certificación Digital, como el Banco Central y el Ente Costarricense de
Acreditación (ECA). A continuación el proceso realizado para esta identificación.
4.2. Identificación de los requisitos
Para la identificación de los requisitos nacionales para implementar una CA en Costa
Rica, la metodología utilizada consistió en la revisión sistemática de los diversos documentos
mencionados en la normativa vigente. La Figura 9 muestra este proceso.
67
Figura 9. Metodología para la identificación de requisitos.
Cada documento fue analizado para encontrar requisitos y referencias a otros documentos que definen requisitos
El punto de partida para la identificación de los requisitos fue la Ley 8454 como documento
creador y base legal de la firma digital en Costa Rica.
4.2.1. Ley 8454 y Reglamento.
La Ley 8454 fue redactada con el objetivo de evitar requisitos explícitos dada la
dificultad y el proceso necesario para realizar enmiendas a leyes de la República de Costa
Rica. El único artículo que menciona requisitos relacionados con los requisitos de una CA es
el artículo 19:
Artículo 19.—Requisitos, trámites y funciones. La Dirección de Certificadores de Firma
Digital será la encargada de establecer, vía reglamento, todos los requisitos, el trámite y las
funciones de las personas que soliciten su registro ante esta Dirección; para ello, el ECA, a
solicitud del Ministerio de Ciencia y Tecnología, deberá fijar los requerimientos técnicos
para el estudio, de acuerdo con la Ley Nº 8279, de 2 de mayo de 2002, y las prácticas y los
estándares internacionales. [3]
Con base en el artículo anterior, la DCFD publicó en 2006 el Reglamento a la Ley de
Certificados, Firmas Digitales y Documentos Electrónicos [4], que define los requisitos que
debe cumplir una entidad para poder registrarse como Autoridad Certificadora dentro del
Sistema Nacional de Certificación Digital. En particular los artículos 6, 11, 19 y 20 que se
muestran en la Tabla 10 son los que especifican requisitos para una CA.
Ley8454 ReglamentoalaLey8454
PolíticadeCertificados
Estándaresmencionados
68
Tabla 10. Requisitos especificados por el Reglamento a la Ley 8454.
Sección Requisito
Artículo 6°
En el caso de los certificados digitales que vayan a ser utilizados en procesos de firma digital y de autenticación de la identidad, los certificadores necesariamente deberán: 1. Utilizar al menos un proceso de verificación y registro presencial (cara a
cara) de sus suscriptores. 2. Guardar copia de la documentación utilizada para verificar la identidad de la
persona. 3. Registrar de forma biométrica (fotografía, huellas digitales, etc.) al suscriptor
a quién le será emitido un certificado. 4. Requerir el uso de módulos seguros de creación de firma, con certificación
de seguridad que se indique conforme a las normas internacionales y a las Políticas establecidas por la DCFD.
5. Establecer un contrato de suscripción detallando el nivel de servicio que ofrece y los deberes y responsabilidades de las partes.
6. La DCFD podrá establecer cualquier otro requisito que considere pertinente, en tanto emisor y gestor de políticas del sistema de firma digital.
Artículo 11
Comprobación de idoneidad técnica y administrativa. Para obtener la condición de certificador registrado, se requiere poseer idoneidad técnica y administrativa, que serán valoradas por el ECA, de conformidad con los lineamientos técnicos establecidos en las Normas INTE-ISO/IEC 17021 e INTE/ISO 21188 versión vigente, las políticas fijadas por la DCFD y los restantes requisitos que esa dependencia establezca, de acuerdo con su normativa específica.
Artículo 19
Los certificadores registrados tendrán las siguientes atribuciones y responsabilidades: 1. Conservar la información y registros relativos a los certificados que emitan,
durante no menos de diez años contados a partir de su expiración o revocación. En caso de cese de actividades, la información y registros respectivos deberán ser remitidos a la DCFD, quien dispondrá lo relativo a su adecuada conservación y consulta.
2. Mantener un repositorio electrónico, permanentemente accesible en línea y publicado en internet para posibilitar la consulta de la información pública relativa a los certificados digitales que haya expedido y de su estado actual, de la manera que se indique en la Norma INTE /ISO 21188 versión vigente y en los lineamientos que sobre el particular dicte la DCFD.
(continúa)
69
Tabla 10. Requisitos especificados por el Reglamento a la Ley 8454. (continuación)
Sección Requisito
Artículo 20
Divulgación de datos. En adición al repositorio en línea a que se refiere el artículo previo, todo certificador registrado deberá mantener un sitio o página electrónica en Internet, de alta disponibilidad y protegida con esquemas de seguridad razonables para impedir su subplantación, por medio del cual suministre permanentemente al público al menos los datos siguientes, empleando un lenguaje fácilmente comprensible y en idioma español: 1. Su nombre, dirección física y postal, número(s) telefónico(s) y de fax (si lo
tuviera), así como un mecanismo de contacto por medio de correo electrónico.
2. Los datos de inscripción ante la DCFD y su estado actual (activo o suspendido).
3. Las políticas de certificación que aplica y que son respaldados y aprobados por la DCFD
4. El resultado final más reciente de evaluación o auditoría de sus servicios, efectuada por el Ente Costarricense de Acreditación.
5. Cualesquiera restricciones establecidas por la DCFD. 6. Cualquier otro dato de interés general que disponga la Ley, este Reglamento
o la DCFD.
Nótese que de los requisitos especificados en el reglamento, solamente el artículo 11
hace referencia a otros documentos que fue necesario revisar (resaltado del autor):
Artículo 11. Comprobación de idoneidad técnica y administrativa. Para obtener la
condición de certificador registrado, se requiere poseer idoneidad técnica y administrativa,
que serán valoradas por el ECA, de conformidad con los lineamientos técnicos establecidos
en las Normas INTE/ISO/IEC 17021 e INTE/ISO 21188 versión vigente, las políticas
fijadas por la DCFD y los restantes requisitos que esa dependencia establezca, de
acuerdo con su normativa específica.
En primer lugar, debe notarse la presencia del estándar INTE/ISO/IEC 17021 [33], ya
que éste no está relacionado con PKI o ningún otro aspecto informático. Este estándar define
los principios y requerimientos para revisar la competencia, consistencia e imparcialidad de
organizaciones que realizan auditorías de sistemas de gestión en organizaciones. Después de
consultar con la DCFD, se encontró que el objetivo original de este requisito era que las
Autoridades Certificadoras fueran capaces de auditar y certificar de manera formal a las
70
Autoridades de Registro que utilizaran para la distribución de los certificados digitales del
SNCD. Este requisito no ha sido implementado aún. Los requisitos para la implementación
de una Autoridad de Registro están especificadas en una Política publicada por la DCFD
[34]. Por recomendación de la DCFD este requisito así como la revisión de dicho estándar
fue ignorado, ya que existe un consenso a nivel de la DCFD para remover este requisito (el
17021) en el corto plazo.
El segundo estándar que se menciona es la norma internacional ISO 21188:2006 Public
key infrastructure for financial services -- Practices and policy framework4. Esta norma
expone una serie de objetivos de control que son necesarios para la implementación de una
Autoridad Certificadora en Infraestructuras de Llave Pública en entidades financieras.
Finalmente, el artículo 11 establece que la DCFD puede establecer políticas que serán
de implementación de obligatoria. La principal política establecida por la Dirección es la
Política de Certificados para la jerarquía nacional de certificadores registrados [35], en
adelante referido como CP. El CP contiene la definición de la política de certificados para la
Infraestructura de Llave Pública del Sistema Nacional de Certificación Digital, y fue
realizado con base en el RFC3647 [23].
4.2.2. Política de Certificados
La Política de Certificados del SNCD indica que las autoridades certificadoras
registradas deben implementar las políticas en los servicios de certificación que incluyen: la
emisión, gestión, suspensión y revocación de los certificados. Además indica que el
documento describe “las políticas de acatamiento obligatorio que deben ser implementadas
4 El INTE/ISO 21188 y el ISO 21188:2006 Public key infrastructure for financial services -- Practices and policy framework se refieren al mismo documento. El primero es la versión traducida por INTECO (ente representante de la ISO en Costa Rica) para uso a nivel nacional, sin embargo ambos documentos tienen el mismo contenido.
71
por la Autoridad Certificadora Raíz y por cualquier otra Autoridad Certificadora Registrada
en los niveles inferiores de la jerarquía nacional de certificadores registrados” [35].
En la introducción del CP se indica además que: “Sin embargo, este documento no
pretende ser una guía exhaustiva para la evaluación del cumplimiento de los requisitos
necesarios para un proceso de acreditación. La guía detallada para la evaluación de una
autoridad certificadora que desea incorporarse al sistema de certificación nacional, debe
solicitarse a la DCFD, y la misma se adhiere a los lineamientos establecidos en: la norma
INTE-ISO-21188:2007 Infraestructura de llave pública para servicios financieros —
Estructura de prácticas y políticas” [35]. Sin embargo, al consultar a la DCFD sobre esta guía
detallada, se indicó que la misma aún no ha sido elaborada y en cambio se hizo referencia a
una guía de revisión que se maneja para las visitas de auditoría que regularmente hace la
Dirección en las Autoridades Certificadoras registradas.
El CP define requisitos no sólo para la implementación de Autoridades Certificadoras,
sino que incluye también aspectos relacionados con todos los actores de una Infraestructura
de PKI, por ejemplo suscriptores, certificados (formato y extensiones), autoridades de
registro, entre otros. En relación con las Autoridades Certificadoras, el CP incluye requisitos
con respecto a:
§ Responsabilidades de publicación de información y del repositorio de certificados.
§ Requerimientos operacionales del ciclo de vida del certificado.
§ Controles operacionales, de gestión y de instalaciones.
§ Controles técnicos de seguridad.
§ Auditoría de cumplimiento y otras evaluaciones.
§ Otros asuntos legales y comerciales.
72
De particular interés resulta el contenido de la sección 8 del CP, Auditoría de
cumplimiento y otras evaluaciones, ya que menciona una serie de requisitos que debe cumplir
toda CA en el SNCD, por ejemplo:
§ “Cada CA debe implementar un programa de auditorías internas para la verificación
de su sistema de gestión. Dicho programa de auditorías debe estar basado en la
INTE-ISO/IEC 19011 “Directrices para la auditoría de sistemas de gestión de la
calidad y/o ambiental.”
§ “Las CA emisoras dentro de la jerarquía nacional de certificadores registrados deben
cumplir con las políticas nacionales y con los estándares determinados, a saber:
o Ley y reglamento de firma digital,
o Políticas de la raíz para los certificados de:
§ Firma digital y autenticación de persona física.
§ Firma digital y autenticación de agente electrónico.
o INTE/ISO 21188: Infraestructura de llave pública para servicios financieros.
Estructura de prácticas y políticas.
o RFC 3647: Internet X.509 Public Key Infrastructure. Certificate Policy and
Certification Practices Framework.”
Por último se analizó la guía de revisión para auditorías y visitas desarrollada por la
DCFD. Esta guía está compuesta por una serie de ítems divididos en categorías, pero no hace
referencia a ningún otro documento, por lo que los requisitos que contiene fueron
recopilados.
73
4.3. Requisitos identificados
En resumen, después de revisar todos los documentos especificados y de consultar con
la DCFD, los siguientes son los documentos que contienen requisitos:
§ Ley 8454: Ley de Certificados, Firmas Digitales y Documentos Electrónicos.
§ Reglamento a la Ley 8454.
§ Política de Certificados.
§ Guía detallada para la evaluación de una CA (DCFD).
§ INTE–ISO–21188:2007.
§ RFC 3647.
§ ISO 17021: ¨Requirements for bodies providing audit and certification of
management systems¨
La Figura 10 muestra estos documentos y la relación entre ellos a nivel de referencias
entre ellos mismos. Con los documentos identificados, se revisó cada documento con el fin
de extraer cada uno de los requisitos que contienen. Los resultados obtenidos se muestran en
la Tabla 11. En total se identificaron 593 requisitos, la mayoría de ellos pertenecen a la
Política de Certificados o al ISO-21188.
Con base en los requisitos identificados se procedió a realizar dos tareas adicionales. En
primer lugar se creó un conjunto de los requisitos que debe cumplir una Autoridad
Certificadora en Costa Rica. Esto se realizó comparando los distintos requisitos de cada
documento y eliminando los requisitos duplicados o semánticamente iguales. Este proceso
se realizó de forma cuidadosa, tratando siempre de no emitir un criterio o de eliminar un
requisito si no estaba duplicado o contenido en otro.
74
Figura 10. Referencias existentes entre los documentos analizados.
Las flechas indican una referencia explícita en el documento fuente del documento destino.
Tabla 11. Requisitos identificados en cada uno de los documentos analizados.
Documento Cantidad de Requisitos
Ley 8454 1
Reglamento a la Ley 8454 10
Política de Certificados 209
ISO-21188 340
Requisitos Técnicos-CA-PF 33
Total 593
En total, se obtuvieron 416 requisitos únicos que una Autoridad Certificadora debe
cumplir para operar en Costa Rica. Además cada requisito se categorizó según su enfoque,
naturaleza u objetivo de control. Esta lista de categorías se muestra en la Tabla 12 junto con
75
el número de requisitos identificados para cada una de ellas. Por su extensión la lista completa
de requisitos se muestra en el Apéndice B de este documento.
Tabla 12. Lista de categorías de requisitos definidas
Se presenta el nombre dado a la categoría, una breve descripción y el número de requisitos identificados.
Categoría Descripción # Proceso de Registro Requisitos referentes al proceso de registro utilizado por
las Autoridades Certificadoras para la emisión de certificados.
11
Certificaciones & Estándares
Requisitos referentes a las certificaciones tanto técnicas como administrativas que debe tener una Autoridad Certificadora para funcionar dentro del SNCD.
4
Conservación de Registros Requisitos referentes a la conservación de registros por
parte de una Autoridad Certificadora.
1
Validación de Certificados
Requisitos referentes al proceso de validación de certificados que debe realizar y ofrecer una Autoridad Certificadora del SNCD.
24
Personal de la CA Requisitos que cada Autoridad Certificadora debe cumplir con respecto al personal que emplea.
17
Requisitos Financieros Requisitos financieros, pólizas y seguros que cada
Autoridad Certificadora debe proveer.
2
Requisitos Legales Requisitos legales que cada Autoridad Certificadora debe cumplir.
7
Documentación Requisitos referentes a la documentación que cada Autoridad Certificadora debe proveer.
9
Seguridad Física y Ambiental Requisitos de seguridad física y ambiental que cada
Autoridad Certificadora debe tener.
23
Publicación de Información
Requisitos referentes a la información que cada Autoridad Certificadora debe publicar y mantener accesible públicamente.
9
(continúa)
76
Tabla 12. Lista de categorías de requisitos definidas (continuación)
Categoría Descripción # Gestión de la
continuidad del negocio
Requisitos de gestión de continuidad del negocio que cada Autoridad Certificadora debe cumplir. 19
Desarrollo de Software
Requisitos de desarrollo de software que cada Autoridad Certificadora debe tener. 7
Dispositivos Criptográficos
Requisitos de los dispositivos criptográficos que cada Autoridad Certificadora utiliza. 14
Administración de Equipo
Computacional
Requisitos de los equipos computacionales que cada Autoridad Certificadora utiliza. 28
Acceso a las Instalaciones
Requisitos referentes al acceso de personal autorizado y no autorizado a los equipos críticos que cada Autoridad Certificadora utiliza.
7
Seguridad de la Información
Requisitos referentes a la seguridad de la información que cada Autoridad Certificadora almacena, transmite y manipula.
19
Política de Certificado
Requisitos de documentación de las prácticas de certificación que cada Autoridad Certificadora realiza. 13
Roles y Funciones Requisitos para la definición de los roles y funciones de los empleados de cada Autoridad Certificadora. 10
Infraestructura de Red
Requisitos de la infraestructura de red que cada Autoridad Certificadora implementa. 7
Gestión de Operaciones
Requisitos para la gestión de las operaciones que cada Autoridad Certificadora realiza. 5
Administración Llave de la CA
Requisitos referentes a la administración de las llaves que cada Autoridad Certificadora posee. 29
Bitácoras y Registros de Auditorías
Requisitos referentes a las bitácoras y registros de auditorías que cada Autoridad Certificadora debe tener. 30
(continúa)
77
Tabla 12. Lista de categorías de requisitos definidas (continuación)
Categoría Descripción #
Emisión de Certificados
Requisitos referentes al proceso de emisión de certificados que cada Autoridad Certificadora debe proveer.
28
Autenticación Requisitos referentes a los escenarios en los cuáles se debe autenticar a usuarios que utilizan los sistemas de la Autoridad Certificadora.
9
Generación Llaves Requisitos de las llaves de una Autoridad Certificadora dentro de la Jerarquía Nacional de Certificadores Registrados.
10
Dispositivos Criptográficos Usuario Final
Requisitos que los dispositivos criptográficos utilizados por los usuarios finales deben cumplir.
19
Procesos de Auditoría
Requisitos referentes a los procesos de auditoría que debe realizar una Autoridad Certificadora del SNCD.
10
Autoridades de Registro
Requisitos que debe de cumplir una Autoridad de Registro (RA) asociada a una Autoridad Certificadora (CA) del SNCD.
7
Uso del Certificado Requisitos referentes a los lineamientos de uso de los certificados emitidos dentro de la Jerarquía Nacional de Certificadores Registrados.
6
Revocación de Certificados
Requisitos referentes al proceso de revocación de certificados que debe realizar y ofrecer una Autoridad Certificadora del SNCD.
8
Suspensión de Certificados
Requisitos referentes al proceso de suspensión que debe realizar y ofrecer una Autoridad Certificadora del SNCD.
13
Terminación de una CA
Requisitos referentes al proceso de terminación que debe realizar una Autoridad Certificadora del SNCD.
1
Formato Certificados
Requisitos referentes al formato de los certificados generados por una Autoridad Certificadora del SNCD.
7
Respaldos de Información
Requisitos referentes a los respaldos de información debe realizar una Autoridad Certificadora del SNCD.
3
En segundo lugar, se procedió a crear un instrumento de evaluación utilizando como
preguntas los 416 requisitos identificados. El diseño de este instrumento, el cual no está
dentro de los objetivos de este trabajo de investigación aplicada, se realizó en coordinación
78
con la DCFD para fomentar un debate sobre los requisitos reales que debe cumplir una
autoridad certificadora en Costa Rica.
La encuesta se organizó en grupos de preguntas según las categorías identificadas. La
encuesta fue aplicada a expertos en Firma Digital del país, seleccionados por la Dirección de
Certificadores de Firma Digital, durante los meses de mayo a julio de 2016, con el fin de
obtener retroalimentación sobre cada uno de los requisitos actuales. El resultado de este
debate será utilizado como insumo para la creación de un esquema de certificación como
parte del proyecto de investigación Desarrollo de esquemas para certificar autoridades y
aplicaciones de software en el Sistema Nacional de Certificación Digital (SNCD)
mencionado en el capítulo 1.
Una vez seleccionados los estándares que serán utilizados y habiendo identificado los
requisitos que tiene que implementar una Autoridad Certificadora en Costa Rica, el siguiente
paso es comparar los requisitos que establece cada estándar con los requisitos actuales para
una CA, con el fin de evaluar si cada estándar podría ser utilizado en Costa Rica. Los
resultados obtenidos se presentan en el siguiente capítulo.
79
5. Aplicabilidad de los Estándares
Este capítulo presenta el proceso realizado para la evaluación de la aplicabilidad de los
estándares seleccionados anteriormente (ISO-21188, Webtrust y ETSI TS 101/102) con
respecto a los requisitos identificados en el capítulo anterior. Se describen inicialmente los
principios de la evaluación, la metodología utilizada para realizar esta evaluación, y los
resultados obtenidos después de realizar la evaluación de cada uno de los estándares.
5.1. Principios de Evaluación
Con el fin de realizar la evaluación de la aplicabilidad de los estándares se asumió como
verdad base que los requisitos identificados en el capítulo anterior son los requisitos mínimos
para implementar una Autoridad Certificadora en Costa Rica. No se realizó ninguna
evaluación con respecto a la validez, pertinencia, lógica o necesidad de los requisitos
identificados. Un análisis de este tipo se podría realizar, pero está por fuera del alcance de
este trabajo.
Se consideró que los requisitos especificados actualmente son requeridos dentro de un
marco legal, lo que hace que sean necesarias modificaciones legales para modificar los
requisitos en el caso de la Ley 8454 y el reglamento asociado, de resoluciones nuevas de la
DCFD para la política de certificados y la guía de implementación y una versión nueva
publicada por la ISO para la norma ISO-21188. En resumen los requisitos de los siguientes
documentos deben ser revisados durante un proceso de auditoría sobre cualquier CA del
SNCD:
§ Ley 8454: Ley de Certificados, Firmas Digitales y Documentos Electrónicos.
§ Reglamento a la Ley 8454.
§ Política de Certificados.
80
§ Guía detallada para la evaluación de una CA (DCFD).
§ Políticas de la DCFD.
o Firma digital y autenticación de persona física.
o Firma digital y autenticación de agente electrónico.
§ INTE–ISO–21188:2007.
§ RFC 3647.
§ ISO 17021: “Requirements for bodies providing audit and certification of
management systems”
Se describe a continuación la metodología utilizada para la evaluación de los estándares
seleccionados.
5.2. Metodología
Para analizar la aplicabilidad de los estándares inicialmente se planteó la pregunta de
¿Se puede utilizar alguno de los estándares analizados como requisito para la implementación
de una Autoridad Certificadora en Costa Rica? Sin embargo, conforme se avanzó en la
investigación, se hizo claro que iba a ser poco probable que alguno de los estándares
evaluados incluyeran todos los requisitos definidos en los múltiples documentos evaluados.
Para solventar esta situación se procedió a diseñar una serie de escenarios de
aplicabilidad. Los escenarios fueron definidos de forma descendente según la cantidad de
estándares, políticas y documentos que deben ser evaluados en un proceso de auditoría. Un
estándar se define como aplicable en Costa Rica para la auditoría de Autoridades
Certificadoras habilitadas dentro del Sistema Nacional de Certificación Digital si:
1. La auditoría puede realizarse en Costa Rica dentro de los parámetros y requisitos del
Sistema Nacional de Calidad [36].
81
2. Se puede utilizar el estándar como uno de los elementos de auditoría en alguno de los
escenarios definidos.
3. El estándar no contiene elementos adicionales a los definidos por los requisitos
actuales a nivel nacional.
Este último requisito conlleva otro aspecto del análisis que debe ser tomado en cuenta.
Para cada estándar se debe analizar también si existen requisitos definidos en el estándar que
no son solicitados a nivel nacional. Este análisis se hace a nivel de los objetivos de control
que define cada estándar. Esto es importante, ya que existe la posibilidad de que un estándar
incluya requisitos que en Costa Rica no son necesarios. Si esto sucede, ninguna CA nacional
podría pasar una auditoría del estándar en cuestión sin implementar los requisitos adicionales.
En este caso, sería importante evaluar el por qué estos requisitos adicionales no son
requeridos en Costa Rica y considerar si deberían agregarse a los requisitos actuales.
Para evaluar cada estándar se inició el análisis en el primer escenario, en el momento en
que se encontraba algún elemento incompatible con los requisitos del escenario, se descartó
este escenario y se inició el análisis del segundo escenario, y de igual forma al encontrar un
elemento incompatible, se descarta éste y se inició el análisis del siguiente escenario y así
sucesivamente. Se presentan a continuación los principales escenarios definidos.
5.2.1. Escenarios definidos
En el primer escenario definido, idealmente se busca que un estándar contenga todos los
requisitos necesarios definidos actualmente para implementar una Autoridad Certificadora
en Costa Rica. Esto significa que la aprobación de una auditoría basada en el estándar es
suficiente para poder cumplir con todos los requisitos. Bajo este escenario, sería posible por
ejemplo, reducir o inclusive eliminar los requisitos incluidos actualmente en el gran número
de documentos analizados en el capítulo anterior, ya que estos estarían especificados en el
estándar. No se debería utilizar ningún otro documento para el proceso de auditoría. En el
82
caso de este escenario, la aplicabilidad de un estándar es una decisión binaria, es decir, este
contiene todos los requisitos o no los contiene.
En el segundo escenario, se busca un estándar que contenga objetivos de control que
impliquen la revisión de toda la documentación técnica y legal pertinente como parte del
proceso de auditoría. Esto permitiría asegurarse que los requisitos definidos actualmente en
estos documentos (la guía de implementación, la política de certificados, la ley y el
reglamento, por ejemplo) sean incorporados dentro del proceso de auditoría. En este
escenario la definición del estándar como único requisito sería suficiente, ya que como parte
del proceso de auditoría del estándar todos los documentos necesarios serían auditados. Note
que en este escenario, si existiera algún requisito definido por fuera del estándar pero
contenido en alguno de los documentos referenciados, el mismo proceso de auditoría lo
evaluaría al revisar estos documentos. Para ilustrar el proceso de auditoría realizado en este
escenario, el lector puede considerar un grafo compuesto por un nodo por cada documento
de requerimientos que debería ser analizado y un nodo adicional para el estándar, en donde
las aristas representan referencias o dependencias entre dos documentos dados. Si al iniciar
un recorrido de los nodos del grafo empezando en el nodo del estándar (lo que representaría
iniciar un proceso de auditoría utilizando el estándar), si al terminar el recorrido todos los
nodos (documentos) han sido visitados, entonces se puede asegurar que al realizar una
auditoría con el estándar, todos los documentos relevantes van a ser analizados.
En el tercer escenario, se tiene un estándar que no incluye como parte del proceso de
auditoría al menos uno de los documentos requeridos. En la analogía anterior, el grafo
contendría al menos un nodo que no es visitado durante el recorrido. En este caso, para
especificar los requisitos de implementación de una CA, sería necesario definir cuál estándar
se usaría y adicionalmente se deberían especificar los requisitos que no están contenidos en
el proceso de auditoría del estándar. En este escenario cualquier requisito que no estuviera
en el estándar definido puede simplemente ser agregado a una lista de requisitos adicionales.
Note que cualquier estándar puede acomodarse en el tercer escenario, ya que inclusive en el
83
peor de los casos, la lista completa de requisitos podría ponerse en la lista de requisitos
adicionales.
La complejidad del proceso de auditoría crece conforme se avanza en los escenarios. En
el primer escenario, un auditor internacional capacitado para evaluar el estándar internacional
podría aplicar la misma metodología utilizada en evaluaciones en otros países u
organizaciones para realizar la auditoría de las CA en Costa Rica. El resultado del proceso
de auditoría sería suficiente para la DCFD para verificar el cumplimiento de los requisitos.
En el segundo escenario, se tendría que adaptar la metodología de auditoría para incluir la
revisión de los documentos referenciados de forma indirecta en el estándar. Aun así, el
resultado del proceso de auditoría sería todavía suficiente para poder evaluar el cumplimiento
de todos los requisitos definidos a nivel nacional. En el último escenario, el resultado de la
auditoría del estándar no es suficiente. La DCFD debería definir la metodología para la
revisión de los requisitos de la lista adicional. Se presentan a continuación los resultados
obtenidos al evaluar la aplicabilidad de los 3 estándares seleccionados para esta
investigación.
5.3. ETSI
Debido al período de transición en el que se encuentran los estándares a nivel europeo
explicado en la sección 3.5, los estándares europeos anteriores no fueron analizados para
verificar su aplicabilidad. Este proceso podrá ser realizado a partir de las versiones finales de
los nuevos estándares de la familia ETSI 319 411. Las familias de estándares anteriores, la
TS 101/102 y la anterior familia 319 411 quedaron obsoletos el 1 de Julio de 2016. Esto
quiere decir que:
1. Ninguno de estos estándares son legalmente válidos en los países de la Unión
Europea a partir de esta fecha.
2. Ninguno de estos estándares va a ser mantenido ni actualizado más.
84
3. Los organismos de certificación a nivel internacional van a dejar de realizar
auditorías de estos estándares paulatinamente.
4. Todas las Autoridades Certificadoras que deben de cumplir la legislación europea
tendrán que adaptar sus prácticas a los nuevos estándares. Estos tienen hasta el
setiembre de 2018 para realizar la migración [30].
Además, aunque los estándares nuevos entraron en vigencia en Julio de 2016, a nivel europeo
todavía no se ha definido ni el proceso ni la metodología que se va a utilizar para el proceso
de auditoría. Existen planes para la utilización de esquemas de certificación basados en el
ISO-17065 [30].
Por estas razones, se consideró que realizar el análisis de los estándares obsoletos no
tenía sentido, dado que estos ya están obsoletos y no deberían ser considerados como
opciones para ser aplicados en Costa Rica. Una vez que el proceso de auditoría y certificación
sea definido por el ETSI, se podría analizar si este puede ser aplicado en Costa Rica.
5.4. ISO-21188
Actualmente, la norma ISO-21188 es un requisito especificado en el Reglamento de la
Ley 8454. Por esta razón, dentro de los requisitos identificados en el capítulo anterior, se
incluyó los requisitos de esta norma. Conforme con la metodología descrita, se inició la
evaluación en el primer escenario revisando si hay algún requisito nacional que no esté
contenido dentro de la norma. Al existir requisitos tanto en la Ley, el reglamento y la Política
de Certificados que no están en el estándar, se descartó el escenario 1. La Tabla 13 muestra
algunos ejemplos de requisitos definidos en la Política de Certificados que no están
contenidos en la norma ISO-21188.
85
Tabla 13. Requisitos definidos en la Política de Certificados faltantes en el ISO-21188.
Categoría Requisito
AdministracióndeLlavesdelaAutoridadCertificadora
El procedimiento para la destrucción de llaves privadas debe incluir la autorización para destruirla.
AdministracióndeLlavesdelaAutoridadCertificadora
La CA debe cambiar periódicamente sus llaves de firma, de acuerdo con los años de validez de sus certificados en la jerarquía nacional de certificadores registrados (tiempo de uso) y considerando que el último certificado otorgado debe poder ser verificado durante su vigencia (tiempo operacional)
DispositivosCriptográficos
La CA raíz, las CA de políticas y la CA emisora deben destruir los respaldos de las llaves privadas que han expirado. Para los módulos criptográficos de hardware, estos deben ser limpiados por medio de inicialización de ceros (Zeroize Command).
ValidacióndeCertificados
En el caso de la jerarquía nacional de certificadores registrados, los OCSP son un mecanismo opcional para la CA Raíz y las CA de Políticas, debido a que son pocos los certificados emitidos y por tanto revocados por ellas. La verificación del estado de los certificados para las CA emisoras constituye un factor crítico de seguridad para diversas aplicaciones, por lo tanto deben obligatoriamente implementar los dos métodos de validación: OCSP y CRL.
SeguridaddelaInformación
Los sistemas sensibles de la CA requieren un ambiente informático dedicado y aislado, que implemente el concepto de sede computacional confiable con procesos de auditoria que ejecuten pruebas de seguridad al menos dos veces al año.
SeguridaddelaInformación
Todos los archivos deben mantenerse por un periodo de al menos diez años. Además de mantener los controles para que los archivos puedan ser leídos durante el periodo de retención definido.
SeguridaddelaInformación
La CA debe implementar controles para la eliminación de residuos (papel, medios, equipos y cualquier otro desecho) con el fin de prevenir el uso no autorizado, el acceso o divulgación de información privada y confidencial contenida en los desechos.
(continúa)
86
Tabla 13. Requisitos definidos en la Política de Certificados no definidos en el ISO-21188. (continuación)
Categoría Requisito
SeguridaddelaInformación
Los archivos no deben modificarse o eliminarse por alguna operación no autorizada del equipo de la CA. La CA debe mantener la lista de personas autorizadas a mover los registros a otros medios.
SeguridaddelPersonalLa verificación de registros financieros y crediticios debe ser repetida para el personal de confianza al menos una vez cada tres años.
SeguridaddelPersonal
La CA debe efectuar una rotación de sus roles de trabajo. La frecuencia de la rotación del personal debe ser al menos: una vez cada tres años, para la CA emisora y una vez cada cinco años, para la CA Raíz. Antes de asumir las nuevas labores, el personal debe recibir a una actualización de la capacitación que le permita asumir las tareas satisfactoriamente.
Al analizar la norma con respecto al escenario 2 se encontraron los siguientes objetivos
de control (resaltado del autor):
“La CA debe mantener controles que proporcionen una seguridad razonable de que: • Está cumpliendo con los requisitos legales, regulatorios y contractuales
relevantes” y el primer mecanismo de control especifica que:
“La CA debería tener procedimientos para asegurar que todos los requisitos relevantes legales, regulatorios y contractuales son explícitamente definidos y documentados para cada sistema de información.”
Nótese que aunque el mecanismo de control es opcional, con el objetivo de control
definido durante un proceso de auditoría la CA tiene que mostrar evidencia de que está
cumpliendo con todos los requisitos legales relevantes. A partir de este objetivo de control,
durante un proceso de auditoría el auditor tendría que evaluar si la CA está cumpliendo con
los requisitos especificados en la Ley 8454, y a partir de esta el auditor revisaría el
reglamento. Revisando el reglamento, se tendrían que revisar las políticas y las guías
87
definidas por la DCFD. Básicamente el proceso es el mismo utilizado en el capítulo anterior
para la identificación de los requisitos, este proceso se ilustra en la Figura 11.
Para la revisión de la Política de Certificados, la norma incluye en el capítulo 6 el
siguiente requisito:
“6.2 Declaración de prácticas de certificación (CPS) a) Una autoridad certificadora debe documentar sus prácticas de
certificación. b) Una CPS, o algún equivalente, debe soportar cada CP bajo la cual la CA
emite o produce certificados” Con base en el requisito anterior, el auditor tendría que revisar el CPS de la CA, y
verificar que este especifica los elementos necesarios para el cumplimiento de la política de
certificados. De igual forma podría verse la política de certificados como una política
definida por la DCFD y por el artículo 11 del Reglamento, y verse como una política
requerida más.
El proceso de revisión realizado por un auditor puede verse como se muestra en la Figura
11. El proceso iniciaría con la norma ISO-21188 y seguiría con los requisitos legales y los
requisitos técnicos. De la revisión de la Ley 8454 se extrae la necesidad de revisar el
reglamento. A partir del reglamento se extrae el ISO-17021 y las guías de implementación
definidas por la DCFD. Por el lado del CP, se extraen como requisitos la norma 19101 y el
RFC-3647. Este proceso de revisión permitiría abarcar todos los requisitos actuales, por lo
que la norma ISO-21188 se puede aplicar dentro del escenario 2.
Con respecto a la existencia de requisitos no requeridos definidos en la norma, en este
caso la respuesta es trivial. Al estar la norma ISO-21188 definida como un requisito dentro
del reglamento a la Ley 8454, no existen elementos definidos en la norma ISO-21188 que no
sean requeridos actualmente.
88
Figura 11. Proceso de revisión de los requisitos establecidos para una auditoría que inicie con
la norma ISO-21188.
5.5. Webtrust
En el caso de Webtrust, se inició el análisis en el escenario 1, revisando si hay algún
requisito nacional que no esté contenido dentro de este estándar. Al existir requisitos tanto
en la Ley, el Reglamento y la Política de Certificados que no están en este estándar, se
descartó el escenario 1. Los mismos elementos mostrados en la Tabla 13 no están
especificados en la norma ISO-21188 tampoco están definidos en WebTrust. Al analizar
Webtrust con respecto al escenario 2 se encontraron los siguientes objetivo de control:
“The CA maintains controls to provide reasonable assurance that:
§ It conforms with the relevant legal, regulatory and contractual requirements”
A partir de este objetivo de control, durante un proceso de auditoría, el auditor tendría que
evaluar si la CA está cumpliendo con todos los requisitos legales relevantes. En el caso de
Ley 8454 Reglamento
Política de Certificado
ISO 21188
ISO 17021
RFC 3647
ISO 19011
Checklist Persona Física
Checklist Persona Jurídica
Declaración de Prácticas
de Certificación
89
Costa Rica, el auditor iniciaría revisando la Ley 8454, y siguiendo exactamente el mismo
proceso utilizado para la norma ISO-21188, se procedería a revisar los documentos
mostrados en la Figura 12 en el orden mostrado por las flechas.
Para la revisión de la Política de Certificados, el estándar provee el siguiente criterio de
revisión:
“The CA maintains controls to provide reasonable assurance that its Certification Practice Statement addresses the topics included in its Certificate Policy”
y los siguientes mecanismos de control:
“1. The PA is responsible for ensuring that the CA’s control processes, as stated in a Certification Practice Statement (CPS) or equivalent, fully comply with the requirements of the CP. 2. The CA addresses the requirements of the CP when developing its CPS. 3. The CA assesses the impact of proposed CPS changes to ensure that they are consistent with the CP. 4. A defined review process exists to ensure that Certificate Policy(s) are supported by the CA’s CPS.”
A diferencia del ISO-21188, Webtrust sí define explícitamente la necesidad de que el
proceso de auditoria revise que la CPS de la CA y todas sus prácticas sean revisados para la
conformidad con respecto al CP definido por la Autoridad de Políticas.
De esta manera el proceso de revisión es equivalente al especificado para la norma ISO-
21188. El proceso iniciaría con la revisión de los objetivos de control de WebTrust y seguiría
con los requisitos legales y los requisitos especificados en el CP. De la revisión de la Ley
8454 se extrae la necesidad de revisar el Reglamento. A partir del reglamento se extrae el
ISO-17021, el ISO-21188 y las guías de implementación definidas por la DCFD. Por el lado
del CP, se extraen como requisitos la norma 19101 y el RFC-3647. Este proceso de revisión
permitiría abarcar todos los documentos necesarios para revisar todos los requisitos actuales,
por lo que estándar WebTrust se puede aplicar dentro del escenario 2. Este proceso se muestra
en la Figura 12.
90
Figura 12. Proceso de revisión de los requisitos establecidos para una auditoría que inicie con
WebTrust 2.0 para CA.
Con base en el proceso anterior hay un elemento que hay que resaltar. Si se supusiera
que se quiere utilizar WebTrust como estándar, este proceso no debe implicar tener que
revisar el ISO-21188, requerido actualmente (ya que estaríamos solicitando dos estándares
en vez de solamente uno). Esto quiere decir que para mantener el mismo conjunto de
requisitos actual es necesario comprobar si al sustituir el ISO-21188 con WebTrust 2.0
estamos perdiendo algún objetivo de control previamente definido. Para esto se realizó una
minuciosa comparación entre ambos estándares.
A partir de este análisis se constató que todos los objetivos de control definidos en la
norma ISO-21188 están contenidos en la versión 2.0 de WebTrust. Las diferencias
encontradas incluyen solamente objetivos de control adicionales en WebTrust y requisitos
adicionales dentro de WebTrust para objetivos de control definidos en ambos estándares. En
la Tabla 14 se muestran los objetivos de control que están en WebTrust 2.0 y no están en la
Ley 8454 Reglamento
Política de Certificado
Webtrust for CA 2.0
ISO 17021
RFC 3647
ISO 19011
Checklist Persona Física
Checklist Persona Jurídica
Declaración de Prácticas
de Certificación
91
norma ISO-21188. En el caso del primero, que evalúa la consistencia entre el CP y el CPS
de una CA, no está explícitamente definido en la norma. El segundo, que evalúa el ciclo de
vida de los dispositivos criptográficos está especificado en la norma, pero como
procedimientos de control opcional. La Tabla 15 muestra los objetivos de control que tienen
requisitos adicionales en WebTrust con respecto a la norma ISO-21188.
A partir de los resultados obtenidos, se podría concluir que al substituir la norma ISO-
21888 con WebTrust 2.0 el conjunto de requisitos actuales para implementar una CA en
Costa Rica se mantiene, sin que se disminuyan los controles requeridos actualmente, lo que
evita que se desmejore la seguridad de la Infraestructura en general.
Los elementos que se encuentran en Webtrust y no en el ISO-21188 mostrados en las
Tablas 14 y 15 podrían ser analizados por la DFCD para decidir si son adecuados, necesarios
y pertinentes para ser incorporados como requisitos a nivel nacional. De ser aceptados, habría
también que decidir la compatibilidad de estos elementos con respecto a la norma ISO-21188,
en caso de que se quisiera mantener esta como una auditoría válida para operar en Costa Rica.
Tabla 14. Objetivos de control que son requeridos por Webtrust 2.0 y que no están presentes
en la norma ISO-21188.
Sección Criterio
2.3 CP and CPS
Consistency
The CA maintains controls to provide reasonable assurance that its Certification Practice Statement addresses the topics included in its Certificate Policy.
4.7 CA Cryptographic
Hardware Life Cycle
Management
The CA maintains controls to provide reasonable assurance that: § Devices used for private key storage and recovery and
the interfaces to these devices are tested before usage for
integrity;
§ Access to CA cryptographic hardware is limited to
authorized personnel in trusted roles, using multiple
person control
§ CA cryptographic hardware is functioning correctly.
92
Tabla 15. Objetivos de control que presentan requisitos adicionales en Webtrust 2.0 con respecto a la norma ISO-21188.
Las diferencias entre los estándares se resaltan en negrita.
Criterio en Webtrust Objetivo de control en ISO-21188
The CA maintains controls to provide reasonable assurance that CA system access is limited to authorized individuals. Such controls provide reasonable assurance that:
§ operating system and database access is limited to
authorized individuals with predetermined task privileges;
§ access to network segments housing CA systems is limited
to authorized individuals, applications and services
§ CA application use is limited to authorized individuals.
The CA shall maintain controls to provide reasonable assurance that CA system access is limited to authorized individuals. Such controls shall provide reasonable assurance that:
§ operating system access is limited to authorized
individuals with predetermined task privileges;
§ access to network segments housing CA systems is
limited to authorized individuals, applications and
services;
§ CA application use is limited to authorized individuals.
The CA maintains controls to provide reasonable assurance that CA systems development and maintenance activities are documented, tested, authorized, and properly implemented to maintain CA system integrity.
The CA shall maintain controls to provide reasonable assurance that CA systems development and maintenance activities are authorized to maintain CA system integrity
93
The CA maintains controls to provide reasonable assurance that: § It conforms with the relevant legal, regulatory and
contractual requirements;
§ Compliance with the CA’s security policies and procedures
is ensured;
§ The effectiveness of the system audit process is
maximized and interference to and from the system
audit process is minimized
§ unauthorized CA system usage is detected.
The CA shall maintain controls to provide reasonable assurance that:
§ it conforms with the relevant legal, regulatory and
contractual requirements;
§ compliance with the CA’s security policies and
procedures is ensured;
§ unauthorized CA system usage is detected.
The CA maintains controls to provide reasonable assurance that CA key pairs are generated in accordance with the CA’s disclosed business practices and defined procedures specified within detailed key generation ceremony scripts. The CA’s disclosed business practices include but are not limited to:
1. Generation of CA keys are undertaken in a physically secured
environment (see §3.4);
2. Generation of CA keys are performed by personnel in trusted
roles (see §3.3) under the principles of
3. Multiple person control and split knowledge;
4. Generation of CA keys occur within cryptographic modules
meeting the applicable technical and business
5. Requirements as disclosed in the CA’s CPS;
The CA shall maintain controls to provide reasonable assurance that CA key pairs are generated in accordance with defined key generation ceremony scripts and the requirements of the CPS.
94
6. Generation of CA keys are witnessed by an independent party
and/or videotaped; and
7. CA key generation activities are logged.
The CA key generation script includes the following: 1. Definition of roles and participant responsibilities;
2. Approval for conduct of the key generation ceremony;
3. Cryptographic hardware and activation materials required
for the ceremony;
4. Specific steps performed during the key generation ceremony;
5. Physical security requirements for the ceremony location;
6. Procedures for secure storage of cryptographic hardware and
activation materials following the key generation ceremony;
7. Sign-off from participants and witnesses indicating whether
key generation ceremony was performed in accordance with
the detailed key generation ceremony script; and
8. Notation of any deviations from the key generation
ceremony script.
If the CA (or RA) distributes subscriber key pairs and certificates using Integrated Circuit Cards (ICCs), the CA (or RA) maintains controls to provide reasonable assurance that:
§ ICC procurement, preparation and personalization are
securely controlled by the CA (or RA or card bureau)
If the CA (or RA) distributes subject key pairs and certificates using integrated circuit cards (ICCs), the CA (or RA) shall maintain controls to provide reasonable assurance that:
§ ICC procurement, preparation and personalization are
securely controlled by the CA (or RA or card bureau);
95
§ ICC Application Data File (ADF) preparation is securely
controlled by the CA (or RA)
§ ICC usage is enabled by the CA (or RA or card bureau) prior
to ICC issuance
§ ICC deactivation and reactivation are securely
controlled by the CA (or RA)
§ ICCs are securely stored and distributed by the CA (or RA
or card bureau)
§ ICCs are securely replaced by the CA (or RA or card bureau)
§ ICCs returned to the CA (or RA or card bureau) are securely
terminated.
§ ICC usage is enabled by the CA (or RA or card bureau)
prior to ICC issuance;
§ ICCs are securely stored and distributed by the CA (or
RA or card bureau);
§ ICCs are securely replaced by the CA (or RA or card
bureau);
§ ICCs returned to the CA (or RA or card bureau) are
securely terminated.
96
6. Conclusiones
Se presentan a continuación las conclusiones obtenidas durante la realización de este
proyecto de investigación. Además se describen algunos resultados adicionales obtenidos
durante el desarrollo del proyecto y finalmente se listan algunos elementos de trabajo
adicional que se pueden realizar para continuar el proyecto.
A partir de los resultados obtenidos durante el proyecto de investigación se puede
concluir que los siguientes estándares son los más utilizados para la certificación y auditoría
de Autoridades Certificadoras en Infraestructuras de Llave Pública:
§ Trust Service Principles and Criteria for Certification Authorities Version 2.0 –
Webtrust.
§ ETSI TS 102 042 Policy requirements for certification authorities issuing public key
certificates
§ ISO 21188:2006 Public key infrastructure for financial services -- Practices and
policy framework.
Estos son aceptados no solo por diversos Gobiernos a nivel mundial, sino también por
sistemas operativos y exploradores web para la incorporación de una llave pública de una
CA en su repositorio de certificados.
Por otro lado, después de revisar toda la legislación nacional vigente (leyes,
reglamentos, políticas, guías de implementación y estándares) se pudo obtener la siguiente
lista de documentos que son los que especifican todos los requisitos necesarios para la
implementación, auditoría y certificación de una Autoridad Certificadora registrada en el
Sistema Nacional de Certificación Digital de Costa Rica:
§ Ley 8454: Ley de Certificados, Firmas Digitales y Documentos Electrónicos.
97
§ Reglamento a la Ley 8454.
§ Política de Certificados.
§ Guía detallada para la evaluación de una CA (DCFD).
§ Políticas de la DCFD.
o Firma digital y autenticación de persona física.
o Firma digital y autenticación de agente electrónico.
§ INTE–ISO–21188:2007.
§ RFC 3647.
§ ISO 17021: “Requirements for bodies providing audit and certification of
management systems”
A partir de los documentos anteriores se encontraron 593 requisitos, de los cuáles 416
fueron identificados como requisitos únicos. Estos fueron clasificados en 34 diferentes
categorías con base en la naturaleza de los requisitos. Por último, al comparar los estándares
analizados con respecto a los requisitos identificados se llegó a las siguientes conclusiones:
1. La Política de Certificados (CP) contiene 209 requisitos que deben ser implementados
por una Autoridad Certificadora en Costa Rica. Muchos de estos requisitos no están
presentes en los estándares analizados por lo que al evaluar la conformidad de las
Autoridades Certificadoras actuales se deben evaluar los requisitos contenidos no
solo en el estándar, sino en el CP.
2. Una porción significativa de los requisitos que están en la Política y no en los
estándares se debe a la definición de criterios más específicos y/o restrictivos que los
presentes en los estándares. Muchos de los elementos definidos son críticos para la
implementación de la CA.
98
3. Existen diversos requisitos que no están en la Política de Certificados, pero si están
en el estándar ISO-21188, el cuál es requisito por reglamento para una CA en Costa
Rica.
4. La versión 2.0 de Webtrust contiene todos los objetivos de control que contiene la
norma ISO-21188 ya que la nueva versión de Webtrust fue realizada a partir de la
versión final del ISO-21188 en el año 2011.
5. Un proceso de auditoría definiendo como requisito inicial el cumplimiento de la
norma ISO-21188 o WebTrust para CA 2.0 va a incluir dentro del proceso de
evaluación la revisión de todos los requisitos que son necesarios actualmente para
implementar una CA en Costa Rica dentro del SNCD, ya que ambos estándares
incluyen la revisión de la Política de Certificado y la legislación nacional relevante
como uno de los objetivos de control.
6. Existen algunos objetivos de control adicionales en WebTrust 2.0 que no están
presentes en la norma ISO-21188. Además algunos objetivos tienen requisitos
adicionales. Para evaluar si WebTrust puede ser aceptado como alternativa a la norma
se debe decidir si estos requisitos son válidos y necesarios.
7. Actualmente no es factible para las Autoridades Certificadoras en el país cumplir con
todos los requisitos legales especificados en la legislación nacional, ya que la norma
ISO-21188 no es acreditable, como se requiere en el Reglamento a la Ley 8454. Por
otro lado, la lista de requisitos está dividida en múltiples documentos, con elementos
repetidos y algunos definidos de una forma poco clara o ambigua.
6.1. Impacto
Este trabajo es el primer esfuerzo que se realiza a nivel académico en Costa Rica para
analizar los distintos estándares que se utilizan para certificar Autoridades Certificados en
Infraestructuras de Llave Pública. A partir de los resultados en este trabajo la DCFD podría
99
realizar un análisis de los requisitos necesarios para implementar una Autoridad Certificadora
en Costa Rica con el fin:
§ Verificar si la escogencia de la norma ISO-21188 como base de los requisitos fue
adecuada y si se puede utilizar como punto de partida de un proceso de auditoría
para las CA del SNCD.
§ Verificar si se puede utilizar el estándar WebTrust 2.0 para CA como sustituto de la
norma ISO-21188.
§ Verificar si alguno de los requisitos identificados debe ser actualizado, modificado
o eliminado.
§ Verificar si requisitos adicionales identificados en WebTrust 2.0 debe ser agregado
como requisito a nivel nacional.
Con base en los resultados obtenidos se podría publicar una nueva versión del
Reglamento y de la Política de Certificados en la cual se solucionen los problemas actuales,
se refinen los requisitos solicitados y se simplifiquen los procesos de auditoría.
6.2. Trabajo Futuro
Con los resultados obtenidos se pueden realizar diversos esfuerzos adicionales para
mejorar el Sistema Nacional de Certificación Digital. En primera instancia, a partir de la
identificación de todos los requisitos que se solicitan actualmente, es posible realizar un
trabajo de revisión de estos, con el fin de evaluar su utilidad. Con este propósito fue que se
creó el instrumento de evaluación que se mencionó en el Capítulo 4. La idea es que expertos
a nivel nacional en temas de firma digital, criptografía y PKI puedan opinar sobre la
necesidad o no de cada requisito. A partir de las opiniones recolectadas, la DCFD podría
analizar si existen requisitos que no son necesarios o si existen elementos que deben
agregarse. Tomando en cuenta que la implementación de firma digital en Costa Rica inició
en el año 2005 con la Ley 8454 y los trabajos anteriores a ésta, parece razonable hacer una
100
revisión de la normativa 10 años después, especialmente si se considera el auge de nuevas
tecnologías para el comercio, banca y gobierno electrónico y el proceso de masificación del
uso de la firma digital que ha impulsado el Poder Ejecutivo en Costa Rica.
Una vez identificados los requisitos que se deberían de requerir actualmente, el siguiente
paso que se podría realizar es crear un esquema formal de certificación que permita las
Autoridades Certificadoras realizar procesos de auditoría que permitan incrementar el nivel
de confianza de todos los actores (público en general, gobierno, sector público y privado)
hacia el SNCD. Para esto se podría desarrollar un esquema de certificación propio, con base
en el estándar ISO/IEC 17067:2013 Conformity assessment -- Fundamentals of product
certification and guidelines for product certification schemes [36], el cual brinda los
lineamientos para la creación de esquemas de certificación que son auto administrados. Este
estándar por ejemplo se utiliza para definir esquemas de certificación de seguridad, de
alimentos, de calidad entre otros. La característica principal es que la administración del
estándar, así como de la definición de requisitos necesarios para obtener su certificación es
competencia únicamente del dueño del estándar. Esto permite la definición de esquemas de
certificación que pueden ser modificados cuando sea necesario por el ente administrador del
esquema, al contrario de lo que pasa por ejemplo cuando se necesita modificar un estándar
internacional como el ISO-21188 o los estándares europeos de la ETSI, en los cuáles
cualquier modificación necesita ser aprobada por los miembros del organismo.
El ISO-17067 brinda toda la infraestructura para la definición de un esquema de
certificación diseñado a la medida de los requisitos necesarios, incluyendo referencias a
estándares internacionales que se consideren necesarios. Además permite el diseño de
sistemas de esquemas de certificación, en los cuáles es posible definir jerarquías de
esquemas, en los cuáles los requisitos comunes a diversas situaciones pueden ser abstraídas
en esquemas superiores y permitir la certificación de distintos escenarios, en este caso por
ejemplo, se podrían desarrollar esquemas para certificar la CA Raíz, CA Políticas y CA
emisores, definiendo los requisitos comunes (la gran mayoría) en un esquema superior, y los
101
elementos específicos en esquemas específicos para cada tipo de CA, como se muestra en la
Figura 13.
Figura 13. Posible sistema de certificación definido con base en el ISO-17067 para la
certificación de CA del SNCD.
6.3. Recomendaciones
A partir de los resultados obtenidos en esta investigación hay varios elementos
interesantes que se pueden analizar:
§ Webtrust 2.0 contiene todos los objetivos de control definidos por la norma ISO-
21188.
§ Ninguno de los estándares contiene todos los requisitos actualmente solicitados, por
lo que elementos adicionales deben ser especificados en alguno de los documentos
normativos (Ley, Reglamento, Políticas).
§ Tanto Microsoft como Mozilla han eliminado el estándar ISO-21188 como un
certificación válida para poder incluir el certificado de la CA raíz en el repositorio
de certificados de Windows, Internet Explorer, Firefox y transitivamente en Chrome
y Opera.
§ Después de conversaciones con la DCFD se concluyó que tener el ISO-17021 como
requisito para una CA en Costa Rica no es necesario.
Fundamentado en los elementos anteriores se podría:
EsquemaGeneraldeCA
EsquemaCARaízyPolíticas
EsquemaCAEmisora
102
§ Eliminar del artículo 11 del Reglamento de la Ley 8454 el ISO-17021 como requisito
para la implementación de una CA en Costa Rica.
§ Eliminar del artículo 11 del Reglamento de la Ley 8454 el ISO-21188 como requisito
para la implementación de una CA en Costa Rica.
§ Diseñar un esquema de certificación con base en el ISO-17067 que permita que una
Autoridad Certificadora pueda ser certificada con base en un esquema definido para
el SNCD.
§ Utilizar el instrumento de evaluación diseñado en este trabajo para generar un proceso
de revisión de los requisitos que actualmente son necesarios para una CA en Costa
Rica.
§ Que el esquema de certificación diseñado especifique como requisitos técnicos:
o El estándar Trust Service Principles and Criteria for Certification
Authorities Version 2.0 – Webtrust, el cuál al contener los mismos requisitos
que el ISO-21188 hace que los niveles de exigencia sean equivalentes pero
permite obtener acceso a los distintos repositorios de sistemas operativos y
exploradores para el certificado Raíz Nacional.
o La Política de Certificado emitida por la DCFD.
o La Políticas definidas por la DCFD.
§ Modificar el artículo 11 del Reglamento de la Ley 8454 para incluir como requisito
único de idoneidad técnica la obtención de la certificación del esquema de
certificación diseñada en el punto anterior.
Con base en las recomendaciones anteriores una propuesta tentativa del artículo 11 sería:
Artículo 11. Comprobación de idoneidad técnica y administrativa. Para obtener la condición de certificador registrado, se requiere poseer idoneidad técnica y administrativa, certificada por un ente acreditado ante el ECA, de conformidad con
103
el esquema de certificación para Autoridades Certificadoras del Sistema Nacional de Certificación Digital versión vigente, las políticas fijadas por la DCFD y los restantes requisitos que esa dependencia establezca, de acuerdo con su normativa específica.
Esto permitiría que las Autoridades Certificadores puedan obtener una certificación que
pruebe su idoneidad técnica y administrativa, además cumpliría con el requisito estipulado
en el artículo de la Ley 8454 el cual indica que cualquier tipo de certificación debe ser
realizada por un ente acreditado ante el ECA.
6.4. Resultados Adicionales
Durante el desarrollo de la investigación conforme se iba revisando material, se
realizaban reuniones con el ECA, la DCFD y el Banco Central se realizaron algunos trabajos
adicionales a los objetivos especificados originalmente para este trabajo. Se presentan a
continuación una breve descripción de cada uno y en los apéndices se muestran los resultados
obtenidos.
6.4.1. Curso de PKI
Con base en el trabajo realizado durante este proyecto, se reunió material suficiente para
poder diseñar un curso de nivel de pregrado o grado enfocado en la teoría e implementación
de Infraestructuras de Llave Pública. El curso además permitiría introducir al estudiante en
conceptos básicos de criptografía, seguridad y estándares referentes al tema. El curso fue
diseñado con un enfoque teórico práctico, con el fin de que los estudiantes no sólo estudien
los conceptos teóricos de los elementos antes mencionados, sino que también puedan poner
en práctica el manejo de certificados digitales, firmas digitales, y el desarrollo de sistemas
que utilizan certificados de llave pública para implementar servicios de autenticación,
integridad, firma y confidencialidad. Temas que por falta de tiempo generalmente no son
impartidos como parte del curso de Redes de un programa de pregrado y que hasta el
momento no ha sido impartido a nivel de posgrado, a pesar de su importancia para el
104
profesional en Ciencias de la Computación y la relevancia que el uso de firmas y certificados
digitales tiene y tendrá en el futuro de los sistemas de información en Costa Rica.
El curso fue diseñado como un curso optativo, de 4 créditos, el cual tiene como requisitos
los cursos de Redes de Computadores e Ingeniería de Software II. Para esto se presenta en el
Apéndice A el diseño preliminar de un programa de curso que tiene el objetivo de introducir
al estudiante a los principales conceptos de PKI, permitiéndole obtener al menos un manejo
práctico de los principales escenarios de firma digital y autenticación. La idea es que el curso
pueda impartirse en la ECCI en algún momento, tanto a nivel de pregrado como a nivel de
Maestría, ya que permitiría a los estudiantes entrar en contacto con tecnologías y elementos
de seguridad que difícilmente son cubiertos en otros cursos de la carrera. En el caso de los
estudiantes de posgrado el curso adquiere todavía más importancia, ya que la mayoría de
estos estudiantes ya están en contacto con desarrollo de sistemas a nivel profesional, por lo
que el aporte se extiende a la calidad de los sistemas desarrollados y a la universalización del
uso de firma digital en los sistemas desarrollados a nivel nacional.
6.4.2. Autoridad de Registro de OID
Un OID o identificador de objeto por sus siglas en inglés, es un identificador que se
utiliza en computación para nombrar un objeto que requiere de un nombre de forma
persistente para su publicación o posterior referencia. Este mecanismo de identificación de
objetos fue desarrollo por la ITU-T y la ISO/IEC con el objetivo de proveer un mecanismo
único de identificación de objetos a nivel mundial.
Estructuralmente los OID se almacenan en un árbol, en el cual la raíz puede tener uno
de 3 valores:
§ 0: ITU-T
§ 1: ISO
§ 2: joint-iso-itu-t
105
Cada uno de los arcos que uno recorre hasta llegar a una hoja brinda más información
sobre la jerarquía de los objetos que contiene ese subárbol. Un OID consiste en un nodo (una
hoja) que se asigna en un espacio de nombres jerárquico, utilizando el estándar de la ITU-T
para ASN.1, X.690. La muestra ejemplos de OID y su significado.
Cuando se revisó la Política de Certificados se encontró que esta está identificada de
forma única con el OID 2.16.188.1.1.1.1. Este indica que el OID pertenece a la rama de joint-
iso-itu-t (2), 16 corresponde al arco asignados a OID de países, y 188 corresponde a Costa
Rica. Sin embargo al consultar el repositorio oficial correspondiente publicado por la ITU-T
se encontró que ninguno de los OID actualmente asignados han sido asignados oficialmente,
por lo que utilización del OID correspondiente se hace de manera informal y no tiene
relevancia o persistencia a nivel global. Después de revisar documentación, estándares
internacionales y repositorios de OID disponibles se descubrió que:
§ El arco 2.16 está reservado como un espacio para que los países registren sus OID.
Es generalmente utilizado por el sector público. Los códigos de los países utilizados
siguen el código numérico de cada país especificado en el estándar ISO 3166-1.
§ Cada subnodo del árbol de OID está a cargo de una Autoridad de Registro, que es el
ente encargado de recibir, evaluar y resolver las solicitudes de asignación de nodos
y arcos por debajo del nodo que manejan. En el caso del arco 2.16, la recomendación
es que existe una Autoridad de Registro Nacional definida por los representantes de
los representantes oficiales de cada país ante ITU e ISO.
§ En el caso de Costa Rica estos corresponden al MICITT en el caso de ITU y a
INTECO en el caso de la ISO.
§ El proceso de creación de una Autoridad de Registro Nacional no debe ser ratificada
por una resolución conjunta ITU-T SG 17 and ISO/IEC JTC 1/SC 6 quiénes son los
subgrupos responsables de Rec. ITU-T X.660 | ISO/IEC 9834-1. Sin embargo, una
vez que se ha creado la Autoridad de Registro para un país dado, se recomienda
106
enviar una carta informando a los subgrupos ITU-T SG 17 and ISO/IEC JTC 1/SC
6, para que se pueda actualizar el registro del OID superior 2.16, {joint-iso-itu-t(2)
country(16)}
§ Entre los elementos necesarios para crear una Autoridad de Registro a nivel nacional
están:
§ Disponer de un sitio web que permita la solicitud en línea de los registros
deseados.
§ Establecimiento de políticas con respecto a los niveles más altos de la jerarquía.
§ Definición de políticas de información, mercadeo y publicación de la
disponibilidad del registro de OIDs.
Con base en lo anterior se realizó una reunión con el director de la DCFD con el fin de
exponerle los elementos encontrados y proponer la creación de un nuevo proyecto de
investigación aplicada con el fin de desarrollar una herramienta para el registro en línea de
solicitudes para OID y realizar los esfuerzos a nivel institucional para la creación de una
Autoridad de Registro para Identificadores de Nombre que permita ofrecer la opción de
registrar formalmente OIDs. Este trabajo está en proceso.
6.4.3. Política de Certificado para la Universidad de Costa Rica
Durante el desarrollo del proyecto de investigación Creación de la Nube Académica
Computacional de la UCR, el cual tiene como objetivo crear toda la infraestructura necesaria
para la ejecución de una nube computacional utilizando hardware ubicado en el Centro de
Informática, surgió la necesidad de crear una Autoridad Certificadora que emita certificados
digitales utilizados por los distintos equipos virtuales para poder realizar labores de
autenticación y confidencialidad.
A partir de esto, con base en el trabajo desarrollo en este trabajo de investigación
aplicada se procedió a definir una infraestructura de llave pública, llamada Jerarquía
107
Institucional de Certificadores Registrados, la cual va a ser la Infraestructura utilizada por la
Universidad de Costa Rica para todo desarrollo que involucre certificados digitales a nivel
interno que no necesiten tener funciones de firma digital (para lo cual se utilizaría el
certificado nacional). Para esto, se definió la Política de Certificado de la Jerarquía
Institucional de Certificadores Registrados de la Universidad de Costa Rica en un trabajo
conjunto con el Centro de Informática. Esta Política de Certificados define los requisitos
necesarios para implementar una CA en la Universidad de Costa Rica que emita certificados
válidos y firmados por la CA Raíz institucional. El documento actualmente se encuentra en
revisión por parte del Centro de Informática y el objetivo es enviarlo al Comité Gerencial de
Informática de la Rectoría de la Universidad de Costa Rica para su aprobación y puesto en
práctica durante el año 2017.
108
7. Bibliografía
[1] Gobierno de Costa Rica, «Masificación de la implementación y el uso de la firma digital
en el sector público costarricense,» Diario Oficial La Gaceta, vol. 136, nº 79, pp. 49-51,
04 2014.
[2] GobiernoCR, «Firma Digital superó los 100 mil certificados digitales,» 11 05 2015. [En
línea]. Available: http://gobierno.cr/firma-digital-supero-los-100-mil-certificados-
digitales/. [Último acceso: 15 08 2016].
[3] Asamblea Legislativa de la República de Costa Rica, «Ley de Certificados, Firmas
Digitales y Documentos Electrónicos,» Diario Oficial La Gaceta, vol. CXXVII, nº 197,
p. 4, 13 Octubre 2005.
[4] Dirección de Certificadores de Firma Digital, «Reglamento a la Ley de Certificados,
Firmas Digitales y Documentos Electrónicos,» Decreto Ejecutivo, 2006.
[5] M. Bishop, Computer Security: Art and Science, Addison-Wesley, 2002.
[6] D. R. Shirey, «INTRODUCTION from the SECURITY ARCHITECTURE FOR
INTERNET PROTOCOLS A Guide for Protocol Designs and Standards,» Internet
Engineering Task Force, 1994.
[7] W. Diffie y M. Hellman, «New directions in cryptography,» IEEE Transactions on
Information Theory, vol. 22, nº 6, 1976.
[8] F. Pratt, Secret and Urgent: the Story of Codes and Ciphers, Blue Ribbon Books, 1939,
pp. 254-255.
[9] D. Kahn, The Codebreakers: The Comprehensive History of Secret Communication
from Ancient Times to the Internet, Scribner, 1996.
[10] R. Housley y T. Polk, Planning for PKI, Wiley Computer Publishing, 2001.
[11] E. K. A. W. Johannes A. Buchmann, Introduction to Public Key Infrastructures,
Springer, 2013.
109
[12] S. S. S. F. S. B. R. H. W. P. D. Cooper, «RFC 5280 on Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile,» Network
Working Group, 2008.
[13] International Telecommunications Union, «X.500 protocol architecture,» [En línea].
Available:
http://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf.
[14] W. C. E. Jeff Stapleton, Security without Obscurity: A Guide to PKI Operations,
Auerbach Publications.
[15] International Organization for Standardization, Norma INTE/ISO 21188:2007
Infraestructura de llave pública para servicios financieros - Estructura de prácticas y
políticas, 2007.
[16] Microsoft, «Microsoft Trusted Root Certificate Program: Audit Requirements for
Certificate Authorities,» Microsoft, 2015. [En línea]. Available:
http://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-
certificate-program-audit-requirements.aspx.
[17] Apple, «Apple Root Certificate Program,» [En línea]. Available:
https://www.apple.com/certificateauthority/ca_program.html.
[18] NetMarketShare, «Desktop Operating System Market Share,» [En línea]. Available:
https://www.netmarketshare.com/operating-system-market-
share.aspx?qprid=10&qpcustomd=0.
[19] Mozilla Foundation, «Network Security Services,» [En línea]. Available:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS.
[20] Mozilla Foundation, «Mozilla CA Certificate Inclusion Policy,» [En línea]. Available:
https://www.mozilla.org/en-US/about/governance/policies/security-
group/certs/policy/inclusion/.
[21] Mozilla Foundation, «CA:CertificatePolicyV2.3,» [En línea]. Available:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3.
110
[22] «Adobe Approved Trust List Technical Requirements Version 1.4,» [En línea].
Available: https://helpx.adobe.com/en/acrobat/kb/approved-trust-list2/_jcr_content/
main-pars/ download/file.res/aatl_technical_requirements_v14.pdf.
[23] W. F. R. S. C. M. S. W. S. Chokhani, «RFC 3647 Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices Framework,» Network
Working Group, 2003.
[24] CA/Browser Forum, «CA/Browser Forum,» [En línea]. Available:
https://cabforum.org/information-for-auditors-and-assessors/.
[25] Canadian Institute of Chartered Accountants (CICA), American Institute of Certified
Public Accountants (AICPA). , «Trust Service Principles and Criteria for Certification
Authorities,» 2011.
[26] Network Working Group, «RFC 2527 Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework,» 1999.
[27] J. Verry, «ISO-27001 Cost Estimate: $48,000 Information Security Confidence:
Priceless,» PivotPoint Security, 26 07 2012. [En línea]. Available:
http://www.pivotpointsecurity.com/blog/iso-27001-cost-estimate-48000-information-
security-confidence-priceless/. [Último acceso: 10 08 2016].
[28] North American Energy Standards Board, «WebTrust for Certification Authorities
(CAs) Overview,» 2011.
[29] European Parliament & Council, «Directive 1999/93/EC of the European Parliament and
of the Council of 13 December 1999 on a Community framework for electronic
signatures,» 1999.
[30] I. Barreira, «ETSI TC ESI PRESENTATION TO CAB FORUM,» 2015. [En línea].
Available: https://cabforum.org/wp-content/uploads/ETSI-Presentation-2015-Mar.pdf.
[31] «ETSI – European Telecommunications Standards Institute,» [En línea]. Available:
https://cabforum.org/etsi/. [Último acceso: 3 7 2016].
111
[32] ETSI, «Electronic Signatures and Infrastructures Activities,» ESI, 2016. [En línea].
Available: https://portal.etsi.org/TBSiteMap/esi/ESIActivities.aspx. [Último acceso: 4 7
2016].
[33] International Organization for Standardization, ISO/IEC 17021:2011 Conformity
assessment -- Requirements for bodies providing audit and certification of management
systems, 2011.
[34] Dirección de Certificadores de Firma Digital Ministerio de Ciencia y Tecnología,
«Directrices para las Autoridades de Registro. Características de cumplimiento de
Autoridades de Registro (RA) de la jerarquía nacional de certificadores registrados de
Costa Rica,» 2008.
[35] Dirección de Certificadores de Firma Digital Ministerio de Ciencia y Tecnología,
«Política de Certificados para la Jerarquía Nacional de Certificadores Registrados,»
2015.
[36] Asamblea Legislativa de la República de Costa Rica, «Ley 8279: Sistema Nacional de
Calidad,» Diario Oficial La Gaceta, 21 5 2002.
[37] International Standards Organization, «ISO/IEC 17067:2013 Conformity assessment --
Fundamentals of product certification and guidelines for product certification schemes,»
International Standards Organization.
[38] J. P. Christof Paar, Understanding Cryptography: A Textbook for Students and
Practitioners, Springer, 2009.
[39] «Browser & Platform Market Share May 2016,» [En línea]. Available:
https://www.w3counter.com/globalstats.php.
[40] «Introduction to ASN.1,» 2016. [En línea]. Available: http://www.itu.int/en/ITU-
T/asn1/Pages/introduction.aspx. [Último acceso: 4 7 2016].
112
Apéndice A: Programa de Curso de PKI
A.1. Descripción
Este curso trata sobre el diseño, implementación y uso de Infraestructuras de Llave Pública
(PKI por sus iniciales en inglés) para el logro de objetivos de seguridad de autenticación,
confidencialidad, no repudio e integridad en el desarrollo de sistema de software. Una PKI
es un sistema que utiliza certificados digitales emitidos por una entidad de confianza que se
encarga de validar y asegurar la identidad y validez de los certificados emitidos. El curso
incluye los contenidos necesarios para diseñar, utilizar y validar certificados digitales
emitidos bajo una Infraestructura de Llave Pública e incorporar estos elementos en el proceso
de desarrollo de sistemas informáticos que los utilizan para firmas digitales y autenticación.
A.2. Datos del Curso
Nombre: InfraestructurasdeLlavePública Sigla: CI-XXXX Créditos: 4 Horas: 5 Requisitos: SeguridaddeSistemasComputacionales,ProyectoIntegradorde
IngenieríadeSoftwareyBasesdeDatos Correquisitos: Notiene Clasificación: Cursopropio Ciclo: IIciclo,4eraño(electivadelénfasisenIngenieríaenTecnologíadela
Información)
A.3. Objetivo General
El objetivo general del curso es que cada estudiante sea capaz de diseñar, implementar
y utilizar Infraestructuras de Llave Pública, certificados y firmas digitales como un
mecanismo para la implementación de servicios de seguridad como confidencialidad,
autenticación, no repudio e integridad en aplicaciones de software e infraestructura
tecnológica mediante el estudio de la literatura, legislación relevante, herramientas y la
implementación de pruebas de concepto de este tipo de sistemas.
113
A.4. Objetivos Específicos
En este curso cada estudiante aprenderá a:
a. Diseñar certificados digitales para implementar Infraestructuras de Llave Pública
mediante el estudio de los estándares relevantes y los formatos más utilizados.
b. Definir, especificar e implementar una Infraestructura de Llave Pública para distribuir
certificados digitales de forma segura, apegándose a estándares internacionales mediante
la utilización de herramientas de código abierto.
c. Utilizar certificados digitales e Infraestructuras de Llave Pública para la implementación
de firmas digitales y de servicios de seguridad como autenticación, integridad y
confidencialidad en sistemas de software a través de tareas y proyectos programados.
d. Conocer la legislación vigente, la infraestructura y operación del Sistema Nacional de
Certificación Digital de Costa Rica para poder implementar sistemas de software que
cumplan la legislación nacional a través de la revisión de las políticas, leyes, reglamentos
y política de certificados vigentes.
Transversales
Además, cada estudiante practicará las siguientes habilidades transversales:
1. Buenas prácticas de programación.
2. Buenas prácticas de diseño y construcción de software.
3. Seguridad
4. Aspectos sociales y práctica profesional
114
A.5. Contenidos
Los ejes temáticos del curso y los objetivos a los que contribuyen se muestran en la tabla que sigue:
Objetivo(s) Eje temático Contenido Semanas
1
Certificados Digitales
Conceptos básicos de seguridad: Ataques, amenazas, servicios y objetivos de seguridad, políticas de seguridad y mecanismos de control.
0.5
1 Conceptos básicos de criptografía: Criptografía, Sistemas Criptográficos Clásicos, Criptografía Simétrica. 1
1 Criptografía de Llave Pública: RSA, DES, Funciones Hash, Firmas Digitales, (Implementación, ventajas, desventajas) 1.5
1 Concepto de Certificados Digitales, estándares, estructura (campos y extensiones), formatos, manipulación. 2
2
Infraestructuras de Llave Pública
Concepto, actores: Autoridades Certificadoras, Autoridades de Registro, subscriptores, autoridad de políticas, terceros que confían.
1
2 Arquitecturas de PKI. 0.5
2 RFC3647, Política de Certificados y Declaración de Prácticas de Certificación. 1
2 Implementación: Estándares, Algoritmos, Infraestructura 1
2 Validación de Certificados: CRL, OCSP, Certification Paths, SCVP. 1
2 Manejo de Llaves Privadas: repositorios de llaves, ciclo de vida, dispositivos criptográficos. 1
3 Firmas
Digitales Y servicios de
seguridad Autenticación
Firma de documentos electrónicos 1
3 Verificación de Firmas Digitales. 1
3 Formatos: XAdES, PAdES, CAdES 1
3 Estampado de Tiempo 0.5
3 Autenticación mediante Certificados Digitales 1
4
Sistema Nacional de Certificación
Digital de Costa Rica
Ley 8454, Reglamento, Política de Certificados, Políticas Adicionales, Autoridades Certificadoras, Autoridades de Registro
1
115
A.6. Bibliografía
Texto 1. J. Buchmann et al. “Introduction to Public Key Infrastructures”. Springer, 2013. Apoyo 2. M. Bishop, “Computer Security: Art and Science”. Addison-Wesley, 2002 3. C. Paar et al. “Understanding Cryptography: A Textbook for Students and
Practitioners”. Springer, 2009. 4. R. Housley y T. Polk. “Planning for PKI”. Wiley Computer Publishing, 2001. 5. Jeff Stapleton et al. “Security without Obscurity: A Guide to PKI Operations”.
Auerbach Publications, 2016. 6. Dirección de Certificadores de Firma Digital Ministerio de Ciencia y Tecnología.
“Directrices para las Autoridades de Registro. Características de cumplimiento de Autoridades de Registro (RA) de la jerarquía nacional de certificadores registrados de Costa Rica”. 2008.
7. Dirección de Certificadores de Firma Digital Ministerio de Ciencia y Tecnología. “Directrices para las Autoridades de Registro. Características de cumplimiento de Autoridades de Registro (RA) de la jerarquía nacional de certificadores registrados de Costa Rica”. 2008.
8. Dirección de Certificadores de Firma Digital Ministerio de Ciencia y Tecnología, “Política de Certificados para la Jerarquía Nacional de Certificadores Registrados”. 2015.
9. International Organization for Standardization. “Norma INTE/ISO 21188:2007 Infraestructura de llave pública para servicios financieros - Estructura de prácticas y políticas”. 2007.
10. Asamblea Legislativa de la República de Costa Rica. “Ley de Certificados, Firmas Digitales y Documentos Electrónicos”. Diario Oficial La Gaceta, vol. CXXVII, nº 197, p. 4, 13 Octubre 2005.
11. Canadian Institute of Chartered Accountants (CICA) y American Institute of Certified Public Accountants (AICPA). “Trust Service Principles and Criteria for Certification Authorities”. 2011.
A.7. Metodología Propuesta
El curso será impartido mediante clases magistrales en las cuales el profesor cubrirá los
aspectos teóricos de los contenidos del curso. Durante la primera parte del semestre los
estudiantes realizarán evaluaciones cortas y tareas cortas para poner en práctica la teoría y la
116
práctica de los algoritmos básicos de criptografía. Durante la segunda parte del semestre, los
estudiantes trabajaran en grupos para implementar una Autoridad Certificadora utilizando
herramientas de código abierto, con lo cual podrán poner en práctica los principales
conceptos de PKI. Finalmente en la tercer parte del semestre los estudiantes implementarán
un pequeño sistema que contenga casos de uso típicos de firma digital (autenticación, firma,
verificación). El curso contará con 2 exámenes parciales, y el énfasis de la evaluación estará
orientada en la ejecución de proyectos prácticos que permitan la práctica de los conceptos
estudiados en el curso.
117
Apéndice B: Requisitos para una CA en Costa Rica
Este apéndice contiene los requisitos identificados para la implementación de una
Autoridad Certificadora en Costa Rica. Para la identificación de estos requisitos, como se
explicó en el Capítulo 5 se revisaron los siguientes documento5s:
§ Ley 8454: Ley de Certificados, Firmas Digitales y Documentos Electrónicos.
§ Reglamento a la Ley 8454.
§ Política de Certificados emitida por la DCFD.
§ Guía detallada para la evaluación de una CA (DCFD).
§ Políticas de la DCFD.
§ INTE–ISO–21188:2007.
§ RFC 3647.
Los requisitos recopilados fueron organizados en la categorización definida en el
Capítulo 5. Para cada categoría se listan a continuación los requisitos identificados. Hasta
donde se pudo consultar la reglamentación vigente, la literatura y a través de consultas con
la DCFD y el Banco Central, la siguiente lista es la primera que contiene todos los requisitos
legalmente requeridos para implementar una CA en Costa Rica.
5 Aunque el reglamento a la ley define en el artículo 11 que el ISO 17021: ¨Requirements for bodies providing audit and certification of management systems es un requisito para una CA en Costa Rica, después de reuniones con la DCFD, por recomendación de ellos se decidió excluir esta norma, ya que no ha sido utilizado en ningún momento, y no se considera necesario.
118
B.1 Política de Certificados
Los siguientes requisitos son referentes a los requisitos de documentación de las
prácticas de certificación que cada Autoridad Certificadora realiza:
1. La CP debe especificar el algoritmo(s) de generación de llaves que pueden utilizarse para
generación de llaves de sujeto.
2. La CP debe especificar los tamaños de llave aceptables para generación de llaves de
sujeto.
3. La Política de Certificados debe especificar los requisitos de protección de llaves
privadas, para las llaves privadas de sujeto almacenadas.
4. La Política de Certificados debe especificar los requisitos de protección de la llave
privada, para copias de respaldo de las llaves privadas de sujeto almacenadas por él
mismo.
5. La Política de Certificados debe especificar los requisitos de protección de llaves privadas
para las llaves privadas de sujeto archivadas.
6. La Política de Certificados debe establecer las circunstancias y la autoridad para cuando
la llave privada de sujeto sea restaurada y los procesos de control.
7. El CP debe especificar los requisitos para la destrucción de las llaves de sujeto archivadas,
al final del período de archivo.
8. La Política de Certificados debe especificar los medios a través de los cuales puede ser
ejecutada la destrucción de la llave de sujeto.
9. La Política de Certificados o el CPS debe especificar los requisitos para la destrucción de
todas las copias y fragmentos de la llave privada de sujeto al final del ciclo de vida del
par de llaves.
119
10. Si es requerido, la Política de Certificados debe especificar los requisitos para el uso y
manejo del hardware criptográfico y el proceso de autenticación del sujeto (y las acciones
subsecuentes), cuando el hardware criptográfico se encuentra en otras ubicaciones físicas
(es decir, un HSM conectado a un computador central o servidor remoto).
11. La Política de Certificados debe especificar los requisitos para la notificación a la CA o
la RA, en caso de compromiso de la llave de sujeto.
12. La Política de Certificados padre debe especificar los requisitos para la presentación de
solicitudes de certificación de una sub-CA.
13. La Política de Certificados de una CA padre debe especificar los requisitos para la
presentación de las solicitudes de regeneración de llaves de una sub-CA.
B.2 Requisitos Legales
Los siguientes requisitos son referentes a los requisitos legales que cada Autoridad
Certificadora debe cumplir:
1. Las CA emisoras dentro de la jerarquía nacional de certificadores registrados deben estar
sujetas a las leyes de la República de Costa Rica, en particular de la ley 8454 “Ley de
certificados, firmas digitales y documentos electrónicos” y su reglamento.
2. Si la Autoridad Certificadora escoge delegar una parte de sus roles y las respectivas
funciones a otra parte, la Autoridad Certificadora debe ser, en última instancia, la
responsable de que se lleven a cabo las funciones tercerizadas y la definición y
mantenimiento de una declaración de su CPS.
3. Los controles deben estar establecidos para asegurar el cumplimiento con acuerdos
nacionales, leyes, regulaciones y otros instrumentos para controlar el acceso a, o uso de
hardware y software criptográfico.
120
4. La CA debe tener procedimientos implementados para asegurar el cumplimiento de
restricciones legales en el uso de material, con respecto a los derechos de propiedad
intelectual, y al uso de productos de software propietario.
5. Cualquier tipo de cláusula relativa a la renuncia de garantías debe estar prevista en los
acuerdos de suscriptor y de partes que confían.
6. Las limitaciones de responsabilidad legal deben estar previstas en forma expresa en los
acuerdos de suscriptor y de partes que confían.
7. Los acuerdos de suscriptores y partes que confían deben incluir cláusulas de fuerza mayor
para proteger a la Autoridad Certificadora.
B.3 Requisitos Financieros
Los siguientes requisitos son referentes a los requisitos financieros, pólizas y seguros
que cada Autoridad Certificadora debe proveer. Cada uno corresponde a un elemento
requerido actualmente para una CA.
1. La Autoridad Certificadora debe poseer suficientes recursos financieros para mantener
sus operaciones y ejecutar sus deberes.
2. La Autoridad Certificadora debe ser razonablemente capaz de administrar el riesgo de
responsabilidad para los suscriptores y partes que confían.
B.4 Personal de la CA
Los siguientes requisitos son referentes a los requisitos que cada Autoridad Certificadora
debe cumplir con respecto al personal que emplea y sus requisitos. Cada uno corresponde a
un elemento requerido actualmente para una CA.
121
1. La Autoridad Certificadora debe contar con procedimientos para verificar la experiencia
y los antecedentes del personal que intenta obtener un rol de confianza. Algunos aspectos
de la investigación de antecedentes incluyen:
a. Confirmación de empleos anteriores.
b. Verificación de referencias profesionales.
c. Título académico obtenido.
d. Búsqueda de antecedentes criminales.
e. Verificación de registros financieros y crediticios.
2. La Autoridad Certificadora debe confirmar la identidad y autorización de todo el personal
que intente iniciar labores de confianza. La autenticación de la identidad debe incluir la
presencia física de la persona y una verificación por medio de documentos vigentes de
identificación legalmente reconocidos, tales como la cédula de identidad para los
ciudadanos costarricenses, o el documento único de permanencia, en caso de extranjeros.
3. Los empleados de la Autoridad Certificadora y los que están en roles de confianza, deben
firmar un contrato de confidencialidad (no divulgación) como condición para su
contratación.
4. Las personas seleccionadas para laborar en roles de confianza de la Autoridad
Certificadora deben contar con un contrato y deben:
a. Haber aprobado exitosamente el programa de entrenamiento apropiado.
b. Haber demostrado capacidad para ejecutar sus deberes.
c. Haber aceptado las cláusulas de confidencialidad.
d. No poseer otros deberes que puedan interferir o causar conflicto con los de la CA.
e. No tener antecedentes de negligencia o incumplimiento de labores.
122
f. No tener antecedentes penales.
5. La verificación de registros financieros y crediticios de la Autoridad Certificadora debe
ser repetida para el personal de confianza al menos una vez cada tres años.
6. La Autoridad Certificadora debe proveer los programas de entrenamiento y actualización
a su personal para asegurar que el personal mantiene el nivel requerido de eficiencia para
ejecutar sus labores satisfactoriamente.
7. La Autoridad Certificadora debe capacitar al personal cuando se presenten cambios
significativos en las operaciones de la CA, por ejemplo cuando se producen
actualizaciones de hardware o software, cambios en los sistemas de seguridad, etc.
8. La Autoridad Certificadora debe establecer, mantener y ejecutar procedimientos de
control rigurosos para asegurar la segregación de funciones, basados en las
responsabilidades del trabajo y la cantidad de personas de confianza que ejecutan las
tareas sensitivas.
9. La Autoridad Certificadora debe efectuar una rotación de sus roles de trabajo. La
frecuencia de la rotación del personal debe ser al menos:
a. Una vez cada tres años, para la CA emisora.
b. Una vez cada cinco años, para la CA Raíz.
c. Antes de asumir las nuevas labores, el personal debe recibir a una actualización
de la capacitación que le permita asumir las tareas satisfactoriamente.
10. La Autoridad Certificadora debe suministrar suficiente documentación al personal para
que ejecute un rol, donde se definen los deberes y procedimientos para el correcto
desempeño de su función.
11. La Autoridad Certificadora debe ejecutar las acciones administrativas y disciplinarias
apropiadas contra el personal que violente las normas de seguridad establecidas en esta
123
política o su CPS, de acuerdo a lo estipulado en el contrato de trabajo definido para los
roles de confianza. Además debe llevar un registro de la frecuencia y severidad de las
acciones, con el fin de determinar la sanción que debe ser aplicada.
12. Los usuarios de los sistemas de la Autoridad Certificadora con roles de confianza deben
advertir y reportar cualquier observación o sospecha de debilidades o amenazas en la en
los sistemas o servicios, para asegurar una respuesta apropiada a los incidentes de
seguridad.
13. Al personal de la Autoridad Certificadora que podría ser blanco de coerción, debe
proporcionársele una alarma contra coacción.
14. La Autoridad Certificadora puede contratar personal externo o consultores solamente si
existe una relación claramente definida con el contratista y bajo las siguientes
condiciones:
a. Existe un contrato con cláusulas propias de los roles de confianza y estipula
sanciones para las acciones no autorizadas.
b. No se posee personal disponible para llenar los roles de confianza contratados.
c. Los contratistas o consultores cumplen con los mismos requisitos que el personal
de la CA.
d. Una vez finalizado el servicio contratado se revocan los derechos de acceso.
15. Los contratistas que ejecutan roles de confianza, deben estar sujetos, al menos, al mismo
control de contratación y a los mismos procedimientos de gestión del personal, que los
empleados.
16. Cualquier arreglo contractual entre contratistas y la Autoridad Certificadora, debería
admitir una cláusula de personal contratado temporalmente, que explícitamente permita
124
a la organización tomar medidas contra el personal contratado que viole las políticas de
seguridad de la organización. Las medidas protectoras pueden incluir:
a. Requisitos de garantía en contrato de personal;
b. Indemnización por daños debido a acciones perjudiciales premeditadas del
personal contratado;
c. Multas financieras.
17. Todos los empleados de la Autoridad Certificadora, y cuando sea pertinente, de los
contratistas como terceras partes, deberían recibir un entrenamiento apropiado en
procedimientos y políticas organizacionales.
B.5 Roles y Funciones
Los siguientes requisitos son referentes a los requisitos para la definición de los roles y
funciones de los empleados de cada Autoridad Certificadora. Cada uno corresponde a un
elemento requerido actualmente para una CA.
1. La Autoridad Certificadora debe emplear personal que posea las habilidades,
conocimiento y experiencia relevantes y apropiados para las funciones del trabajo.
2. Los roles y las responsabilidades de seguridad, como se especifican en las políticas de
seguridad de la organización, deberían ser documentas en las descripciones de puestos.
Los roles de confianza sobre los que depende la seguridad de la Autoridad Certificadora,
deberían ser claramente identificados.
3. Los roles de confianza deben incluir, al menos, roles que contemplen las siguientes
responsabilidades:
a. Responsabilidad general de administrar la implementación de las prácticas de
seguridad de la CA;
125
b. Aprobación de la generación, revocación y suspensión de los certificados;
c. Instalación, configuración y mantenimiento de los sistemas de la CA;
d. Operación diaria de los sistemas de la CA, respaldo y recuperación de sistemas;
e. Inspección y mantenimiento de las bitácoras del sistema de la CA y de los
registros de auditoría;
f. Funciones de gestión del ciclo de vida de llaves criptográficas (ejemplo, custodios
de componentes de llaves);
g. Desarrollo de sistemas de la CA.
4. El estatus de confianza de un individuo debe ser aprobado antes de obtener acceso a los
sistemas/instalaciones o ejecutar acciones que requieran de estatus de confianza.
5. Las obligaciones de los cargos y áreas de responsabilidad deben estar segregadas para
reducir las oportunidades de modificación no autorizada o mal uso de la información o
los servicios.
6. Debe existir un procedimiento formal para la registro y cese de los usuarios con roles de
confianza, para otorgar acceso a los servicios y sistemas de la Autoridad Certificadora.
7. La asignación y uso de los privilegios debe ser restringido y doblemente controlado.
8. La asignación de contraseñas u otros mecanismos de autenticación, deben ser controlados
a través de un proceso de gestión formal.
9. Los derechos de acceso para usuarios con roles de confianza deben ser revisados en
intervalos regulares.
10. El personal de la Autoridad Certificadora debe ser provisto de acceso directo solamente
a los servicios que específicamente le han sido autorizados a utilizar. La ruta de acceso
desde la terminal del usuario a los servicios computarizados debe ser controlada.
126
B.6 Dispositivos Criptográficos
Los siguientes requisitos son referentes a los requisitos dede los dispositivos
criptográficos que cada Autoridad Certificadora utiliza. Cada uno corresponde a un elemento
requerido actualmente para una CA.
1. La CA debe generar las llaves mediante un proceso seguro por medio del módulo
criptográfico de hardware, que cumple como mínimo el estándar Fips 140–2 nivel 3 y a
un procedimiento acorde con la “ceremonia de generación de llaves” definida en el anexo
D de la norma INTE/ISO 21188 “Infraestructura de llave pública para servicios
financieros–Estructura de prácticas y políticas.”. La Autoridad Certificadora debe
garantizra que la llave privada de firma nunca permanecerá fuera del módulo donde fue
generada, a menos que se almacene en un mecanismo de recuperación de llaves.
2. La generación de las llaves de los suscriptores requiere que los módulos de criptografía
asociados cumplan al menos con el estándar Fips 140–2 nivel 2, o bien que posean al
menos la certificación Common Criteria EAL 4+ en el perfil de protección SSCD tipo 3.
3. La generación de las llaves de los certificados de persona jurídica requiere que los
módulos de criptografía asociados cumplan al menos con el estándar Fips 140–2 nivel 3,
o bien que posean al menos la certificación Common Criteria EAL 4+ en el perfil de
protección SSCD tipo 3.
4. La TSA debe generar las llaves mediante un proceso seguro, con un módulo criptográfico
de hardware, que cumpla al menos con el estándar Fips 140–2 nivel 3.
5. La integridad del hardware/software utilizados para la generación de llaves y las
interfaces al hardware/software, deben ser probadas antes de su uso en producción.
6. Las políticas y procedimientos deberían requerir que el hardware criptográfico de la
Autoridad Certificadora sea enviado por el fabricante vía correo certificado (o
equivalente) utilizando un empaque evidente a intromisiones (“tamper evident”). Al
127
recibir del fabricante el hardware criptográfico de la Autoridad Certificadora, el personal
autorizado de la Autoridad Certificadora debería inspeccionar el empaque evidente a
intromisiones, para determinar si el sello está intacto.
7. Al recibir del fabricante el hardware criptográfico de la Autoridad Certificadora, deberían
ejecutarse pruebas de aceptación y verificación de la configuración del firmware. Al
recibir el hardware criptográfico de la Autoridad Certificadora, al que se le ha dado
mantenimiento o ha sido reparado, deberían ejecutarse pruebas de aceptación y
verificación de la configuración del firmware.
8. Para prevenir alteraciones (“tampering”), el hardware criptográfico de la Autoridad
Certificadora debería ser almacenado y utilizado en un sitio seguro, con acceso limitado
a personal autorizado, que tenga las siguientes características:
a. Procesos y procedimientos de control de inventario para administrar el origen,
llegada, condición, salida y destino de cada dispositivo;
b. Procesos y procedimientos de control de acceso para limitar el acceso físico a
personal autorizado;
c. Grabar en bitácoras de auditoría todos los intentos exitosos y fallidos de acceso a
las instalaciones de la CA y al mecanismo de almacenaje del dispositivo (ejemplo,
caja fuerte);
d. Procesos y procedimientos de manejo de incidentes para tratar eventos
irregulares, violaciones de seguridad, investigación y reportes;
e. Procesos y procedimientos de auditoría para verificar la efectividad de los
controles.
9. Cuando no esté conectado al sistema de la Autoridad Certificadora, el hardware
criptográfico, debe ser almacenado en un contenedor resistente a violaciones (“tamper
128
resistant”) y debe ser guardado en forma segura, bajo múltiples controles (es decir, una
caja fuerte).
10. El manejo del hardware criptográfico de la Autoridad Certificadora, incluyendo las
siguientes tareas, debe ejecutarse en la presencia de no menos de dos empleados de
confianza:
a. Instalación del hardware criptográfico de la CA;
b. Retiro del hardware criptográfico de la CA de producción;
c. Mantenimiento o reparación del hardware criptográfico de la CA (incluyendo
instalación de nuevo hardware, firmware o software);
d. Desmontaje y remoción permanente de uso.
11. El funcionamiento correcto del hardware criptográfico de la CA debe verificarse
periódicamente.
12. Si un dispositivo criptográfico de la Autoridad Certificadora está siendo retirado
permanentemente de servicio, cualquier llave contenida dentro del dispositivo, que haya
sido utilizada para cualquier propósito criptográfico, debería ser borrada del dispositivo.
13. Los dispositivos utilizados para almacenar y recuperar llaves privadas y las interfaces
hacia estos dispositivos, deben ser probados antes de su uso para verificar su integridad
(ejemplo, siguiendo las instrucciones del fabricante).
14. Las llaves privadas de la CA (de firma y confidencialidad) deben ser almacenadas y
utilizadas dentro de un dispositivo criptográfico seguro que cumpla con el perfil de
protección apropiado de la ISO 15408 o los requisitos del nivel FIPS 140-2, basados en
una evaluación de riesgo y en los requisitos de negocio de la CA, y de acuerdo con la
CPS de la CA y la(s) política(s) de certificado aplicables.
129
B.7 Generación Llaves
Los siguientes requisitos son referentes a los requisitos de las llaves de una Autoridad
Certificadora dentro de la Jerarquía Nacional de Certificadores Registrados.
1. La generación de las llaves de la CA debe llevarse acabo en un ambiente físicamente
seguro, por personal con roles de confianza, bajo los principios de control múltiple y de
conocimiento dividido.
2. La generación de las llaves de la CA debe ser ejecutada de acuerdo con una guía detallada
del protocolo de generación de llaves de la CA, que especifique los pasos a ejecutar y las
responsabilidades de los participantes. La guía de generación de llaves de la CA debe
incluir lo siguiente:
a. Definición de roles y responsabilidades;
b. Aprobación para dirigir el protocolo de la generación de llaves;
c. Hardware criptográfico y materiales de activación requeridos por el protocolo;
d. Pasos específicos ejecutados durante el protocolo de generación de llaves;
e. Procedimientos para el almacenamiento seguro del hardware criptográfico y los
materiales de activación, posterior al protocolo de generación de llaves;
f. Firma de los participantes y testigos indicando si el protocolo de generación de
llaves, fue ejecutado de acuerdo con la guía detallada del protocolo de generación
de llaves;
g. Anotación de cualquier desviación con respecto a la guía del protocolo de
generación de llaves.
3. La generación de llaves de CA debe producir llaves que:
a. Definición de roles y responsabilidades;
130
b. Sean apropiadas para la aplicación o propósito destinado, y que sean
proporcionales a los riegos identificados;
c. Usen un algoritmo aprobado, como se especifica en la ISO 18033, partes 1 a 4 ;
d. Tengan una longitud de llave que sea apropiada para el algoritmo y para el período
de validez del certificado de la CA;
e. Tomen en cuenta los requisitos del tamaño de llave de la CA padre y subordinada;
f. Sean acordes con la CP.
4. La generación de llaves de la CA debería resultar en tamaños de llave acordes con la CP.
La longitud de la llave pública que será certificada por la CA, debe ser menor o igual que
la de la llave privada de firma de la CA.
5. La generación de las llaves de la Autoridad Certificadora debe producirse dentro de un
módulo criptográfico que cumpla con los requisitos de la ISO 15782-1 y los requisitos de
negocio de acuerdo con la CPS. Tales dispositivos criptográficos deberían ejecutar la
generación de la llave utilizando un generador de números aleatorio (RNG por sus siglas
en inglés) o un generador de números pseudo-aleatorio (PRNG) como se especifica en la
ISO 18032.
6. La Autoridad Certificadora debe generar su propio par de llaves en el mismo dispositivo
criptográfico en que será utilizado, o el par de llaves debe ser introducido directamente
desde el dispositivo criptográfico donde fue generado al dispositivo criptográfico donde
será utilizado.
7. Si las llaves privadas de la CA no son exportadas de un módulo criptográfico seguro,
entonces la llave privada de la CA deben ser generada, almacenada y utilizada dentro del
mismo módulo criptográfico.
131
8. La generación de llaves de los sujetos efectuada por la Autoridad Certificadora (la RA o
la oficina de tarjetas) debería ocurrir dentro de un dispositivo criptográfico seguro, que
cumpla con el requisito de nivel de la ISO 15782-1 apropiado, basándose en una
evaluación de riesgo, en los requisitos de negocio de la CA y de acuerdo con la CP
aplicable. Tales dispositivos criptográficos deben efectuar la generación de las llaves de
sujeto utilizando un generador de números aleatorios (RNG) o un generador de números
pseudo-aleatorios (PRNG) como se especifica en la norma ISO/IEC 18032.
9. La CA mantendrá controles para brindar seguridad razonable de que los pares de llaves
de la CA, se generan e instalan de acuerdo con el protocolo definido para la generación
de llaves.
10. La llave de la CA raíz debe tener un tamaño mínimo de 4096 bits. La CA de Políticas
debe mantener llaves con un tamaño mínimo de 2048 bits. Para las CA emisoras debe
tener un tamaño de 2048 bits.
B.8 Administración Llave de la CA
Los siguientes requisitos son referentes a la administración de las llaves que cada
Autoridad Certificadora posee. Cada uno corresponde a un elemento requerido actualmente
para una CA.
1. La Autoridad Certificadora debe mantener controles para asegurar que las llaves privadas
de la CA permanecen confidenciales y mantienen su integridad y el acceso al hardware
criptográfico de la CA está limitado a individuos autorizados.
2. Las llaves privadas de la Autoridad Certificadora deben ser respaldadas, guardadas y
recuperadas por personal autorizado con roles de confianza, utilizando controles
múltiples en un ambiente físicamente seguro.
132
3. Las copias de respaldo de las llaves privadas de la CA Raíz deben estar sujetas al mismo
o mayor nivel de controles de seguridad que las llaves que actualmente están en uso. La
recuperación de las llaves de la CA debe llevarse a cabo de una forma tan segura como
el proceso de respaldo.
4. Para la activación de la llave privada de firma de la Autoridad Certificadora se debe
utilizar controles de acceso de múltiples partes (es decir, “m” de “n”) con un valor
mínimo de 3 para “m”.
5. Si las llaves privadas de la Autoridad Certificadora son respaldadas, estas deben ser
respaldadas, guardadas y recuperadas por personal autorizado con roles de confianza,
utilizando controles múltiples en un ambiente físicamente seguro. La cantidad de
personal autorizado para llevar a cabo esta función debe mantenerse al mínimo.
6. Para la activación de la llave privada de sello electrónico y/o agente electrónico de
persona jurídica se debe utilizar controles de acceso que resguarden la llave privada.
7. Los respaldos de llaves privadas de la Autoridad Certificadora son únicamente para
propósitos de recuperación en caso de una contingencia o desastre.
8. Las llaves privadas de la Autoridad Certificadora son generadas por un módulo
criptográfico seguro. En el evento que una llave privada es transportada desde un módulo
criptográfico a otro, la llave privada debe estar encriptada durante su transporte.
9. La llave privada usada para encriptar el transporte de la llave privada debe estar protegida
contra divulgación no autorizada.
10. Las llaves privadas de la Autoridad Certificadora deben ser almacenadas y utilizadas
dentro de un dispositivo criptográfico seguro que cumpla como mínimo con el perfil de
protección apropiado de los requisitos del estándar FIPS 140–2 nivel 3
11. Los métodos de activación de llaves de la Autoridad Certificadora deben estar protegidos
y para accederlos se debe contar con mecanismos de autenticación de al menos dos
133
factores de seguridad. Los datos de activación deben estar distribuidos en roles de
confianza que ejecutan diversas personas
12. Para la CA Raíz y de Políticas es obligatorio que los módulos criptográficos, los cuales
han sido activados, no estén desatendidos o abiertos al acceso no autorizado. Después de
usarlos, estos deben ser desactivados manualmente o por un tiempo de expiración por
estado pasivo. Los módulos de hardware criptográfico deben ser removidos y
almacenados cuando no estén en uso.
13. El procedimiento para la destrucción de llaves privadas debe incluir la autorización para
destruirla.
14. La CA raíz, las CA de políticas y la Autoridad Certificadora deben destruir los respaldos
de las llaves privadas que han expirado. Para los módulos criptográficos de hardware,
estos deben ser limpiados por medio de inicialización de ceros (Zeroize Command).
15. Los datos de activación de los módulos criptográficos de la CA Raíz y CA de Políticas
deben ser cambiados al menos una vez cada año. En el caso de las CA emisoras la
frecuencia debe ser al menos una vez cada dos meses.
16. Todas las copias y fragmentos de la llave privada de la Autoridad Certificadora deberían
ser destruidos de manera tal que la llave privada no pueda ser recuperada.
17. Si las llaves privadas de la Autoridad Certificadora son exportadas desde un módulo
criptográfico seguro hacia un medio de almacenamiento seguro para propósitos de
procesamiento fuera de línea (“offline”), o respaldo y recuperación, entonces estas deben
ser exportadas dentro de un esquema de gestión de llaves seguro que puede incluir
cualquiera de los siguientes:
a. Texto cifrado, utilizando una llave que esté asegurada apropiadamente;
b. Fragmentos de llave encriptados utilizando controles múltiples y
conocimiento/propiedad dividida;
134
c. Otro módulo criptográfico seguro tal como un dispositivo de transporte de llaves
utilizando control múltiple.
18. La autorización para destruir la llave privada de la CA y el procedimiento de su
destrucción (por ejemplo, entrega del Token, destrucción del Token o sobre-escritura de
llaves), deben limitarse de acuerdo con la CPS de la CA.
19. Las llaves archivadas de la CA deberían estar sujetas al mismo o mayor nivel de control
de seguridad que las llaves que están en uso actualmente.
20. Si es necesario, basándose en una evaluación de riesgo, la activación de la llave privada
de la CA debe efectuarse utilizando autenticación de múltiples factores (ejemplo, tarjeta
inteligente y contraseña, biometría y contraseña, etc.)
21. La llave pública de la Autoridad Certificadora debe ser cambiada (“re-keyed”)
periódicamente, de acuerdo con los requisitos de la CPS. La comunicación de este cambio
debería notificarse con suficiente antelación para evitar interrupciones en los servicios de
la CA.
22. La Autoridad Certificadora debe requerir una revisión anual de las longitudes de llave
(“key length”) para determinar el período de uso de llaves apropiado. Las
recomendaciones deben ser implementadas.
23. En caso que la CA tenga que reemplazar su llave privada de CA raíz, deben existir los
procedimientos para la segura y autenticada revocación de lo siguiente:
a. La llave pública vieja de CA raíz;
b. El conjunto de todos los certificados (incluyendo cualquiera auto-firmado)
emitidos por una CA raíz o cualquier CA, basados en la llave privada
comprometida;
135
c. Cualquier llave pública de CA subordinada y los certificados correspondientes
que requieran re-certificación.
24. Las llaves de firma de la CA, utilizadas para generar certificados y/o para emitir
información del estado de las revocaciones, no deben ser utilizadas para ningún otro
propósito.
25. Las llaves privadas de la CA deben utilizarse únicamente dentro de un sitio físicamente
seguro.
26. La CA debe suspender el uso de un par de llaves al final de la vida operacional definida
para el mismo, o cuando se conoce o sospecha del compromiso de la llave privada.
27. La llave privada de la CA no debe ser destruida hasta que el propósito de negocio o la
aplicación hayan dejado de tener valor o hayan expirado las obligaciones legales.
28. Las llaves archivadas deben únicamente ponerse de vuelta en producción cuando un
incidente de seguridad resulte en una pérdida de las llaves de producción o cuando se
requiera de validación de evidencia histórica. Se deben requerir procesos de control para
asegurar la integridad de los sistemas de la CA y de los conjuntos de llaves.
29. Las llaves archivadas deben ser recuperadas en el menor tiempo posible para satisfacer
los requisitos de negocio.
B.9 Publicación de Información
Los siguientes requisitos son referentes a la información que cada Autoridad
Certificadora debe publicar y mantener accesible públicamente. Cada uno corresponde a un
elemento requerido actualmente para una CA.
1. La Autoridad Certificadora debe mantener un sitio o página electrónica en Internet, de
alta disponibilidad y protegida con esquemas de seguridad razonables para impedir su
136
subplantación, por medio del cual suministre permanentemente al público al menos los
datos siguientes, empleando un lenguaje fácilmente comprensible y en idioma español:
a. Su nombre, dirección física y postal, número(s) telefónico(s) y de fax (si lo
tuviera), así como un mecanismo de contacto por medio de correo electrónico.
b. Los datos de inscripción ante la DCFD y su estado actual (activo o suspendido).
c. Las políticas de certificación que aplica y que son respaldados y aprobados por la
DCFD
d. El resultado final más reciente de evaluación o auditoría de sus servicios,
efectuada por el Ente Costarricense de Acreditación.
e. Cualesquiera restricciones establecidas por la DCFD.
f. Cualquier otro dato de interés general que disponga la Ley, este Reglamento o la
DCFD.
2. La Autoridad Certificadora debe mantener publicada entre otros aspectos, la versión
actualizada de:
a. La política de los certificados que implementa.
b. La plantilla del acuerdo de suscriptor.
c. Los certificados en la cadena de confianza.
d. Las listas de revocación.
3. La Autoridad Certificadora que implemente una política de reembolso debe documentarla
como parte de sus políticas y publicarlas dentro de su sitio Web.
4. El mecanismo inicial de distribución de la llave pública de la CA, debe controlarse como
se documenta en la CPS de la CA. Las llaves públicas de la CA deben ser distribuidas
137
inicialmente dentro de un certificado utilizando uno de los siguientes métodos, de
conformidad con la CPS de la CA:
a. Medios legibles por máquinas (ejemplo tarjeta inteligente, CD ROM), desde una
fuente autenticada;
b. Almacenado en un módulo criptográfico de la entidad;
c. Otros medios seguros que garanticen autenticidad e integridad.
5. El mecanismo de distribución subsiguiente para la llave pública de la CA debe ser
controlado como se documentó en la CPS de la CA.
6. Si una entidad ya tiene una copia autenticada de la llave pública de la CA, una nueva
llave pública de la CA debe ser distribuida utilizando uno de los siguientes métodos de
acuerdo con la CPS de la CA:
a. Transmisión electrónica directa desde la CA;
b. Ubicándola dentro de una reserva (“cache”) o directorio remoto;
c. Cargarla dentro de un módulo criptográfico;
d. Cualquiera de los métodos utilizados para la distribución inicial.
7. La CA debe firmar digitalmente cada CRL que emita, de modo que las entidades puedan
validar la integridad de la CRL y la fecha y hora de emisión.
8. Para entregar la llave pública de la CA a las partes que confían, la Autoridad Certificadora
debe distribuir la llave pública a través del certificado digital y del repositorio público
respectivo.
9. Las llaves públicas transferidas deben ser entregadas a través de mecanismos que
aseguren que la llave pública no se altera durante el tránsito.
138
B.10 Autoridades de Registro
Los siguientes requisitos son referentes a los requisitos que debe de cumplir una
Autoridad de Registro (RA) asociada a una Autoridad Certificadora (CA) del SNCD.
1. La Autoridad Certificadora debe requerir que la RA asegure la parte del proceso de
aplicación del certificado por la cual ella (la RA), asume responsabilidad de acuerdo con
la CPS de la CA.
2. La Autoridad Certificadora debe requerir que las RA, registren sus acciones en una
bitácora de auditoría.
3. La CA debe verificar la autenticidad de los envíos de la RA de acuerdo con la CPS de la
CA.
4. La Autoridad Certificadora debe verificar la firma de la RA en la solicitud de renovación
del certificado.
5. Si una RA acepta solicitudes de revocación, la CA debe requerir que la RA le remita las
solicitudes de revocación de certificado firmadas, en forma autenticada de acuerdo con
la CP.
6. Si una RA acepta solicitudes de suspensión, la RA debe remitir las solicitudes de
suspensión de certificado firmadas a la CA, en forma autenticada de acuerdo con la CP.
7. Es obligatorio que la Autoridad Certificadora supervise las autoridades de registro y
notifique cualquier excepción o irregularidad de las políticas de la jerarquía nacional de
certificadores registrados, y además tome las medidas para remediarlas.
B.11 Proceso de Registro
Los siguientes requisitos son referentes al proceso de registro utilizado por las
Autoridades Certificadoras para la emisión de certificados. Cada uno corresponde a un
elemento requerido actualmente para una CA.
139
1. La Autoridad Certificadora debe utilizar al menos un proceso de verificación y registro
presencial (cara a cara) de sus suscriptores.
2. La Autoridad Certificadora debe guardar copia de la documentación utilizada para
verificar la identidad de la persona.
3. La Autoridad Certificadora debe registrar de forma biométrica (fotografía, huellas
digitales, etc.) al suscriptor a quién le será emitido un certificado.
4. La Autoridad Certificadora debe requerir el uso de módulos seguros de creación de firma,
con certificación de seguridad que se indique conforme a las normas internacionales y a
las Políticas establecidas por la DCFD.
5. La Autoridad Certificadora debe establecer un contrato de suscripción detallando el nivel
de servicio que ofrece y los deberes y responsabilidades de las partes.
6. Al momento del registro (antes de la emisión del certificado) la RA o la CA deben
informar al sujeto o, donde aplique, al suscriptor de los términos y condiciones
concernientes al uso del certificado.
7. Los términos y condiciones bancarias (u otros acuerdos del suscriptor) deben describir
los procesos requeridos a seguir por el suscriptor (y donde aplique el sujeto) para
cualquier uso del mecanismo criptográfico (ejemplo, HSM o ICC y el software de
aplicación)
8. La CA o la RA debe verificar la exactitud de la información incluida en la solicitud del
certificado de la entidad solicitante, de acuerdo con la CP.
9. La CA o la RA debe revisar la solicitud del certificado en busca de errores u omisiones,
de acuerdo con la CP.
140
10. La CA debe requerir que la entidad solicitante de un certificado, prepare y remita los
datos de solicitud del certificado apropiados (solicitud de registro) a una RA (o CA) como
se especifica en la CP.
11. La solicitud de certificado debe ser considerada como una aceptación de los términos y
condiciones por parte de la entidad solicitante, para utilizar el certificado como se
describe en el acuerdo de suscriptor.
B.12 Dispositivos Criptográficos Usuario Final
Los siguientes requisitos son referentes a los requisitos que los dispositivos
criptográficos utilizados por los usuarios finales deben cumplir.
1. Las ICC deben ser protegidas lógicamente durante el transporte entre el fabricante de la
tarjeta y el emisor de la misma, a través del uso de una llave o frase de paso secreta para
el transporte.
2. Las ICC emitidas al suscriptor deben satisfacer el perfile de protección de la ISO/IEC
15408 apropiado, normas ISO de tarjetas (por ejemplo: ISO/IEC 7810, ISO/IEC 7811
(partes 1-5), ISO/IEC 7813, ISO/IEC 7816 (partes 1 – 12 y 15), ISO 10202) o el requisito
de nivel FIPS 140-2(12), basados en una evaluación de riesgo y en los requisitos de la
CP.
3. La oficina de tarjetas deben verificar la integridad física de las ICC al recibirlas del
fabricante de tarjetas.
4. Las ICC deben almacenarse en forma segura y bajo un control de inventario, mientras
estén bajo el control del emisor de tarjetas.
5. Debe existir y seguirse procedimientos y procesos de preparación de las ICC, incluyendo
los siguientes:
a. La carga del sistema operativo de la tarjeta;
141
b. La creación de estructuras de datos lógicas (sistema de archivos y dominios de
seguridad de la tarjeta);
c. La carga de aplicaciones;
d. La protección lógica de la ICC para prevenir modificaciones no autorizadas del
sistema operativo de la tarjeta, sistema de archivos de la tarjeta, dominios y
aplicaciones de seguridad de la tarjeta.
6. Deben existir y seguirse procesos y procedimientos de personalización de la ICC,
incluyendo los siguientes:
a. Cargar la información de identificación en la tarjeta.
b. Generación del par de llaves de sujeto.
c. Cargar la(s) llave(s) privada de sujeto en la ICC (si se genera fuera de la tarjeta)
en forma encriptada.
d. Cargar el certificado de sujeto en la ICC.
e. Cargar el certificado de la CA y otros certificados del ambiente contractual en la
ICC.
f. Protección lógica de la ICC de accesos no autorizados
7. Una ICC debe ser inutilizable a menos que se encuentre en un estado activo.
8. En el caso de pérdida o daño de la tarjeta, los certificados de sujeto deben ser renovados
o reemitidas sus llaves, de acuerdo con la CP.
9. El reemplazo de la ICC deben ser registrado por la oficina de tarjetas, la Autoridad
Certificadora (o la RA) en una bitácora de auditoría.
10. Todas las ICC devueltas a la Oficina de Tarjetas, a la CA (o la RA), deben ser
desactivadas o destruidas en forma segura para prevenir su uso no autorizado.
142
11. La terminación de una ICC debería ser registrada por la oficina de tarjetas, la CA (o la
RA) en una bitácora de auditoría.
12. Se debe proveer al sujeto de mecanismos para proteger el acceso a la información de la
tarjeta, incluyendo las llaves privadas guardadas en la ICC, durante el uso por parte del
suscriptor (es decir, mecanismo de control de acceso por medio de PIN - método de
verificación del tarjetahabiente).
13. Debe existir y seguirse procesos y procedimientos para la distribución, seguimiento y
contabilidad, para la recepción segura de la ICC de suscriptor por parte del sujeto.
14. Los datos de activación inicial de la ICC (ejemplo, PIN de inicialización), deben ser
comunicado en forma segura al sujeto o donde aplique, al suscriptor usando un método
fuera de banda (“out-of-band”). El sujeto, al recibir la tarjeta, debe ser motivado a
cambiar los datos de activación inicial para activarla.
15. La distribución de las ICC debe ser registrada por la oficina de tarjetas, la CA (o la RA)
en una bitácora de auditoría.
16. Si la CA o la RA contrata una oficina de tarjetas entonces debe existir un contrato formal
entre las partes interesadas. Si bien la emisión de tarjetas puede ser delegada a terceras
partes, la CA debe mantener su responsabilidad y obligaciones legales sobre las ICC.
17. Debe existir y seguirse procesos y procedimientos para el reemplazo de una ICC del
sujeto dañada o extraviada.
18. Una ICC no debe emitirse, a menos que la tarjeta haya sido preparada y personalizada
por la oficina de tarjetas, la CA o la RA.
19. El módulo criptográfico para los certificados de persona jurídica debe cumplir como
mínimo con el estándar Fips 140–2, nivel 3, o bien que posean al menos la certificación
Common Criteria EAL 4+ en el perfil de protección SSCD tipo 3.
143
B.13 Emisión de Certificados
Los siguientes requisitos son referentes al proceso de emisión de certificados que cada
Autoridad Certificadora debe proveer. Cada uno corresponde a un elemento requerido
actualmente para una CA.
1. La Autoridad Certificadora tiene la responsabilidad de:
a. Validar la identidad de la RA que remite las solicitudes.
b. Validar la información suministrada en la solicitud.
c. Emitir el certificado de acuerdo con la información suministrada en la solicitud.
d. Enviar el certificado a la RA para que sea entregado al suscriptor.
2. El tiempo de procesamiento de solicitudes de certificados (tiempo entre la solicitud
emitida a la Autoridad Certificadora y la emisión del certificado al suscriptor) de persona
física, cuando el proceso se realice en forma automática, no debe ser mayor a diez
minutos. En cualquier otro caso, las CA y RA procesarán las solicitudes de certificados
dentro de un tiempo razonable, a menos que se especifiquen otros parámetros en el
acuerdo de suscriptor, en la CPS o en otros acuerdos entre los participantes.
3. La Autoridad Certificadora debe verificar que las solicitudes de certificado provengan de
Autoridades de Registro autorizadas.
4. Una vez creado el certificado, la Autoridad Certificadora debe remitirlo a la Autoridad
de Registro desde la cual ingresó la solicitud.
5. Para certificados de sello electrónico y agente electrónico de persona jurídica la
Autoridad Certificadora debe distribuir la llave pública utilizando uno de los siguientes
métodos:
a. Medios legibles por computadoras desde una fuente autenticada;
144
b. Almacenado en un módulo criptográfico de la entidad;
c. Otros medios seguros que garanticen autenticidad e integridad.
6. Para certificados de autoridad de sellado de tiempo (TSA) la llave pública debe ser
entregada mediante un método fuera de banda, tal como:
a. Almacenado en un módulo criptográfico de la entidad;
b. Otros medios seguros que garanticen autenticidad e integridad.
7. El tamaño de las llaves generadas por la Autoridad Certificadora debe ser suficientemente
largo para prevenir que otros puedan determinar la llave privada utilizando cripto–
análisis durante el periodo de uso del par de llaves.
8. El tamaño de las llaves para el suscriptor debe ser de 2048 bits. La longitud de la llave
pública que será certificada por la Autoridad Certificadora, debe ser menor o igual al
tamaño de la llave privada de firma de la CA.
9. La Autoridad Certificadora debe generar y verificar los parámetros de llave pública de
acuerdo con el estándar FIPS 186–2 (Digital Signature Standard–DSS) que define el
cripto–algoritmo utilizado en la generación.
10. La Autoridad Certificadora debe emitir una notificación fuera de banda (“out-of-band”)
al sujeto cuando un certificado es emitido. Cuando esta notificación incluya los datos de
activación inicial, procesos de control deben garantizar la entrega segura al sujeto.
11. La Autoridad Certificadora debe emitir una notificación firmada a la RA, cuando se emita
un certificado a un sujeto, para el cual la RA envió una solicitud de certificado.
12. La CA debe generar los certificados utilizando los datos de la solicitud de certificado y
fabricar el certificado como se define en el perfil de certificado apropiado, de acuerdo
con la ISO- 9594-8 y las reglas de formato de la ISO 15782-1.
145
13. Los períodos de validez de los certificados generados deben ser definidos en la CP y
formateados de acuerdo con la ISO 9594-8 e ISO 15782-1.
14. Los campos de extensión de los certificados generados deberían ser formateados de
acuerdo con la ISO 9594-8 e lSO 15782-1.
15. La CA debe firmar la llave pública y otra información relevante del certificado final, con
la llave privada de firma de la CA.
16. La CA debe verificar la unicidad del “nombre distintivo del sujeto”, dentro de los límites
o comunidad definida por la CP.
17. La Autoridad Certificadora debe utilizar controles de encripción y de acceso para
proteger la confidencialidad e integridad de los datos de registro en tránsito y
almacenados.
18. La CA debe requerir que la entidad solicitante, remita su llave pública en un mensaje
autofirmado a la CA para la certificación. La CA debe exigir que la entidad solicitante
firme digitalmente la solicitud de certificado usando la llave privada que se relaciona con
la llave pública contenida en la solicitud de registro con el fin de:
a. Permitir la detección de errores en el proceso de solicitud del certificado;
b. Confirmar la propiedad de la llave privada correspondiente a la llave pública que
está siendo registrada.
19. Cuando un nuevo certificado es requerido por el suscriptor después de la expiración del
certificado de la entidad, el certificado puede ser generado automáticamente, o se le debe
requerir a la entidad que solicite por un nuevo certificado, de acuerdo con la CP.
20. Si la CA (o RA), genera pares de llaves públicas/privadas de firma, no debe mantener
copia de ninguna llave privada de firma, una vez que el sujeto confirme la recepción de
esa llave.
146
21. Si la CA genera pares de llaves a nombre de un suscriptor, la CA (o RA), debe asegurarse
que las llaves privadas de sujeto no son reveladas a ninguna otra entidad más que al dueño
(es decir, el sujeto) de las llaves.
22. Las llaves privadas de sujeto almacenadas por la CA (o RA), deben ser guardadas en
forma encriptada usando un algoritmo criptográfico y un largo de llave basado en una
evaluación de riesgo y en los requisitos de la CP.
23. Cuando la generación de llaves de sujetos es efectuada por la CA (o la RA o la oficina de
tarjetas), la CA (o la RA o la oficina de tarjetas) debe entregar al sujeto, de forma segura
(confidencialmente), el(los) par(es) de llaves de sujeto generadas por la CA (o la RA o la
oficina de tarjetas), de acuerdo con la CP.
24. La generación de llaves de sujeto efectuada por la CA (o la RA) debe ser efectuada por
personal autorizado de acuerdo con la CPS de la CA.
25. La generación de llaves de sujeto efectuada por la CA (la RA o la oficina de tarjetas)
debe tener como resultado tamaños de llave de acuerdo con la CP;
26. La generación de llaves de sujeto efectuada por la CA (la RA o la oficina de tarjetas)
debe utilizar un algoritmo de generación de llave tal como lo especifica la CP;
27. Los periodos de uso de las llaves generadas son de acuerdo a la siguiente tabla:
Nivel de jerarquía Tiempo de uso en años Tiempo operacional en años
Certificado de usuario 4 4
CA emisoras 8 12
CA Políticas 12 24
CA Raíz 24 48
147
28. La CA no archiva la llave privada de ninguno de los suscriptores. En el caso de la CA,
ésta debe archivar su par de llaves (pública y privada) en forma encriptada en
concordancia con las disposiciones de protección de llaves definidas en este CP, por un
plazo acorde con la legislación aplicable.
B.14 Uso del Certificado
Los siguientes requisitos son referentes a los lineamientos de uso de los certificados
emitidos dentro de la Jerarquía Nacional de Certificadores Registrados.
1. Las llaves privadas del sujeto guardadas en la ICC no debe ser exportadas a una
aplicación para realizar funciones criptográficas (es decir, firma).
2. El sujeto debe estar obligado a utilizar un mecanismo de autenticación mutua para
aplicaciones criptográficas y las funciones de la ICC, con el fin de asegurar la integridad
del sistema.
3. El sujeto debe estar obligado a usar una aplicación que despliegue el mensaje o el
resumen (“digest”) del mismo al sujeto, antes de firmar los datos del mensaje (o
transacción). La aplicación de la ICC del sujeto debe producir bitácoras de auditoría de
todos los usos de la ICC. Esto también incluye todos los intentos en el proceso de
verificación del propietario de la llave privada. Nota: Esta evidencia puede ser presentada
por el sujeto, o donde aplique el suscriptor, si las partes confiantes disputan sobre la
autenticidad y/o integridad de una transacción.
4. La ICC debe ser utilizada por el sujeto, o donde aplique el suscriptor, de acuerdo con los
términos de la CP.
5. La CP debe especificar los usos aceptables para los pares de llaves de sujeto.
6. La CP debe especificar los requisitos para el uso de la llave de sujeto.
148
B.15 Validación de Certificados
Los siguientes requisitos son referentes al proceso de validación de certificados que debe
realizar y ofrecer una Autoridad Certificadora del SNCD.
1. La Autoridad Certificadora debe mantener un repositorio electrónico, permanentemente
accesible en línea y publicado en Internet para posibilitar la consulta de la información
pública relativa a los certificados digitales que haya expedido y de su estado actual, de la
manera que se indique en la Norma INTE /ISO 21188 versión vigente y en los
lineamientos que sobre el particular dicte la DCFD.
2. La Autoridad Certificadora debe proporcionar a las partes que confían la información de
cómo encontrar el repositorio adecuado para verificar el estado del certificado y los
servicios de validación de certificados en línea (OCSP) para la verificación en línea.
3. La CA Raíz debe actualizar su lista de revocación cada cuatro meses y cada vez que se
presente una revocación del certificado de una CA de Políticas, en cuyo caso se debe
notificar a las CA subsecuentes.
4. La CA de Políticas debe actualizar su lista de revocación cada dos meses y cada vez que
se presente una revocación del certificado de una CA emisora, en cuyo caso se debe
notificar a todas las CA emisoras.
5. El estado de los certificados de la Autoridad Certificadora debe estar disponible a través
de los CRL publicados en un sitio Web.
6. Las listas de revocación de certificados de una Autoridad Certificadora debe cumplir con
el RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”
7. La Autoridad Certificadora debe actualizar y publicar las listas de revocación al menos
una vez a la semana. Además deberá publicar los Delta CRL una vez al día.
149
8. La Autoridad Certificadora debe publicar la CRL en el repositorio en un plazo no mayor
a dos horas posterior a su generación.
9. La Autoridad Certificadora debe implementar el servicio de validación en línea OCSP.
10. La Autoridad Certificadora debe mantener los servicios de verificación del estado de los
certificados disponibles 24 x 7 x 365.
11. El servicio OCSP es una característica opcional para la CA de la Raíz y las CAs de
políticas.
12. El servicio OCSP que se implemente debe cumplir lo estipulado en el RFC2560 “X.509
Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”.
13. La CA debe proporcionar un mecanismo para validar la autenticidad e integridad de las
llaves públicas de la CA. Para el proceso de distribución de la CA raíz (ejemplo,
utilizando un certificado auto-firmado), debe utilizarse un mecanismo de notificación
fuera de banda (“out-ofband”). Cuando un certificado auto-firmado es utilizado por
cualquier CA, la CA debe proporcionar un mecanismo para verificar la autenticidad del
certificado auto-firmado (ejemplo, publicación de la huella del certificado). Para llaves
públicas subsiguientes y/o subordinadas, estas deben ser validadas utilizando un método
de encadenamiento o un proceso similar, para asociarlas al certificado raíz de confianza.
Para un nuevo certificado raíz, un proceso fuera de banda (“out-of-band”) puede ser
requerido.
14. La CA debería mantener disponibles los certificados emitidos por la CA, a las partes
relevantes utilizando un mecanismo establecido (ejemplo, un repositorio tal como un
directorio), de acuerdo con la CP. Los mecanismos confiables incluyen:
a. Colección – repositorio o servicio de directorio en línea;
b. Entrega – distribución utilizando medios protegidos (ejemplo, CD-ROM o ICC)
150
15. La Autoridad Certificadora debería actualizar la lista de revocación de certificados (CRL)
y cualquier otro mecanismo con el estado de los certificados, en los periodos establecidos
en la CP y conforme al formato definido en la ISO 9594-8 y la ISO 15782-1.
16. La Autoridad Certificadora debe hacer disponible la información del estado del
certificado a las entidades relevantes (partes que confían o sus agentes), utilizando un
mecanismo establecido de acuerdo con la CP. Esto puede ser logrado utilizando:
a. Un método de respuesta de solicitud – una solicitud firmada por la parte que
confía enviada al servicio de respuesta del proveedor, sobre el estado de
certificados (“certificate status provider´s responder”). De vuelta, el servicio de
respuesta contesta con el estado del certificado debidamente firmado (OCSP es
un protocolo de ejemplo que usa este método);
b. Un método de entrega - una CRL firmada por la CA y publicada conforme a la
periodicidad establecida en la política.
17. La Autoridad Certificadora debe emitir las CRL a intervalos regulares, como se especifica
en la CP, incluso si no han ocurrido cambios desde la última emisión.
18. Como mínimo, se deben mantener registros en la CRL, de todos los certificados
revocados hasta el final del período de validez de los mismos. Además, una vista
retrospectiva del estado de un certificado, en un punto dado del tiempo, puede ser
requerida. Por lo tanto, los registros de la CRL pueden necesitar ser mantenidos más allá
del período de validez de certificado para demostrar su validez en el momento de su uso.
19. Las CRL deben ser archivadas de acuerdo con los requisitos de la CP, incluyendo el
método de recuperación.
20. La CRL debe contener registros para todos los certificados revocados no vencidos
emitidos por la CA. Una vista retrospectiva del estado de un certificado, en un momento
dado del tiempo, puede ser requerida. Por lo tanto los registros de las CRL, pueden
151
necesitar ser mantenidos más allá del periodo de vida del certificado, para probar su
validez al momento de su uso.
21. Las CRL viejas deben ser conservadas por un período apropiado establecido en la CP de
la CA.
22. Si se utiliza un método en línea de recolección de estado de certificados (ejemplo, OCSP),
la CA debe requerir que las consultas sobre el estado de certificados (ejemplo, solicitudes
OCSP) contengan todos los datos requeridos de acuerdo con la CP.
23. Cuando se recibe una solicitud de estado de un certificado (ejemplo, una solicitud OCSP),
proveniente de una parte confiante o su agente, la CA debe retornar una respuesta
definitiva a la parte confiante o a su agente si:
a. El mensaje de solicitud está bien formado;
b. El servicio de respuesta del proveedor de estado de certificados (“certificate status
provider´s responder”) está configurado para proporcionar el servicio solicitado;
c. La solicitud contiene la información (es decir, la identidad del certificado - el
número de serie, OID, etc.) requerida por el servicio de respuesta del proveedor
de estado de certificados de acuerdo con la CP;
d. El servicio de respuesta del proveedor de estado de certificados, es capaz de
localizar el certificado e interpretar su estado.
e. Cuando estas condiciones se cumplan, la CA o el servicio de respuesta sobre el
estado de certificados de la CA debe generar un mensaje de respuesta firmado,
indicando el estado del certificado de acuerdo con la CP. Si cualquiera de las
condiciones anteriores no se cumple, entonces un estado de “desconocido” puede
ser devuelto.
152
24. Los certificados, las listas de revocación (CRL) y otras entradas en la bases de datos de
revocación debe contener información de fecha y hora. Esta información de fecha y hora
no necesita tener una base criptográfica, pero si debe estar sincronizada con el servicio
de tiempo de la UTC–6.
B.16 Revocación de Certificados
Los siguientes requisitos son referentes al proceso de revocación de certificados que
debe realizar y ofrecer una Autoridad Certificadora del SNCD.
1. La CA debe proveer de un medio de comunicación rápido para facilitar la revocación
segura y autenticada de lo siguiente:
a. Uno o más certificados de uno o más sujetos;
b. El conjunto de todos los certificados emitidos por una CA, basados en un par de
llaves pública/privada específico, utilizado por una CA para generar certificados;
c. Todos los certificados emitidos por la CA, sin importar del par de llaves
publica/privada utilizado.
2. La CA debería verificar, o requerir a la RA que verifique, la identidad y autoridad de la
entidad que solicita la revocación de un certificado de acuerdo con la CP.
3. Si una RA acepta y reenvía una solicitud de revocación a la CA, la CA debe brindar una
confirmación firmada de la solicitud de revocación y una confirmación de las acciones a
la RA solicitante.
4. La CA debe registrar todas las solicitudes de revocación y su resultado en una bitácora
de auditoría, como se especifica en el Anexo F de la ISO 15782-1.
5. La CA o la RA puede brindar una confirmación autenticada (firmada o similar) de la
revocación a la entidad que realizó la solicitud de revocación.
153
6. Donde se permita la renovación de certificados, cuando un certificado es revocado, todas
las instancias válidas del certificado también deben ser revocadas y no deben ser
reestablecidas.
7. Cuando un nuevo certificado es requerido por el suscriptor después de la revocación, se
debe requerir a la entidad que aplique por un nuevo certificado, de acuerdo con la CP.
8. Las solicitudes de revocación deben ser procesadas en un rango de tiempo razonable, de
acuerdo con el procedimiento para la solicitud de revocación. Cuando la solicitud
provenga del suscriptor y se utilicen mecanismos electrónicos automatizados, la
revocación debe realizarse en forma inmediata.
B.17 Suspensión de Certificados
Los siguientes requisitos son referentes al proceso de suspensión que debe realizar y
ofrecer una Autoridad Certificadora del SNCD.
1. El sujeto (y donde aplique, el suscriptor) de un certificado revocado o suspendido debe
ser informado del cambio de estado de su certificado.
2. La CA debe provee un medio de comunicación rápido para facilitar la suspensión segura
y autenticada de lo siguiente:
a. Uno o más certificados de uno o más sujetos;
b. El conjunto de todos los certificados emitidos por una CA, basados en un par de
llaves pública/privada específico, utilizado por la CA para generar certificados;
c. Todos los certificados emitidos por una CA, sin importar el par de llaves
publica/privada utilizado.
3. La CA debe verificar, o requerir a la RA que verifique, la identidad y autoridad de la
entidad que solicita la suspensión o reactivación de un certificado de acuerdo con la CP
154
4. La CA o la RA debería notificar al sujeto y, donde aplique, al suscriptor, en el caso de
una suspensión del certificado.
5. Las solicitudes de suspensión de certificado deben ser procesadas y validadas de acuerdo
con los requisitos de la CP.
6. La CA debería actualizar la CRL y otros mecanismos de estado de certificados, cuando
se realice la suspensión de un certificado. Los cambios en el estado del certificado deben
completarse en el tiempo establecido por la CP.
7. Los certificados deben ser suspendidos sólo por el tiempo permitido de acuerdo con la
CP.
8. Una vez que la suspensión (retención) del certificado ha sido emitida, la suspensión debe
ser manejada en una de las siguientes tres formas:
a. Un registro del certificado suspendido permanece en la CRL sin más acciones;
b. El registro en la CRL para el certificado suspendido es sustituido por una entrada
de revocación para el mismo certificado;
c. El certificado suspendido explícitamente es liberado y la entrada removida de la
CRL.
9. Un registro de la suspensión (retención) del certificado debe permanecer en la CRL hasta
la expiración del certificado en cuestión o la expiración de la suspensión, la que ocurra
primero. La CP puede especificar el número máximo de veces en que un certificado puede
ser suspendido y el período máximo para este estado. Si el límite es alcanzado, la PA
puede ser notificada para mayor investigación.
10. La Autoridad Certificadora debe actualizar la CRL y otros mecanismos con el estado de
certificados, cuando se levante la suspensión a un certificado de acuerdo con la CP de la
CA.
155
11. La CA debe verificar, o requerir que la RA verifique, la identidad y autoridad de la
entidad que solicita que se levante la suspensión de un certificado.
12. La suspensión de certificado y el levantamiento de suspensión de certificado debe ser
registrada en una bitácora de auditoría, como se especifica en el Anexo F de la ISO
15782-1:2003
13. Si la suspensión de certificados es ofrecida, un registro de la suspensión (retención) del
certificado debe permanecer en la CRL, indicando la fecha de la acción original y la fecha
de expiración, hasta la expiración normal del certificado o hasta que la suspensión sea
levantada.
B.18 Infraestructura de Red
Los siguientes requisitos son referentes a los requisitos de la infraestructura de red cada
Autoridad Certificadora implementa.
1. Los controles (ejemplo, firewalls) deben estar instalados para proteger el dominio de la
red interna de la Autoridad Certificadora de cualquier acceso no autorizado desde
cualquier otro dominio.
2. Los controles deben estar instalados para limitar los servicios de la red (ejemplo, HTTP,
FTP, etc.) y mantenerlos disponibles a los usuarios autorizados, de acuerdo con las
políticas de control de acceso de la Autoridad Certificadora. Los atributos de seguridad
de todos los servicios de red utilizados por la organización de la Autoridad Certificadora,
deberían ser documentados por la Autoridad Certificadora.
3. Los controles de enrutamiento deben estar instalados para asegurar que las conexiones
de las computadoras y la circulación de la información, no violen las políticas de control
de acceso de la Autoridad Certificadora.
156
4. La CA debe asegurar que los componentes de la red local (ejemplo, firewalls,
enrutadores) se mantengan en un ambiente físicamente seguro y sus configuraciones
deben ser periódicamente auditadas en cumplimiento con los requisitos de configuración
de la CA.
5. Los datos sensibles deben estar encriptados cuando se intercambian sobre redes públicas
o no confiables.
6. En el caso de la Autoridad Certificadora Raíz, ésta debe estar offline y aislada de la red
organizacional.
7. El equipo de la CA debe estar dentro de los límites de la red interna, operando bajo un
nivel de seguridad de red crítico. La red de la CA debe estar protegida contra ataques.
Los puertos y servicios que no se requieran deben estar apagados. Los niveles críticos de
seguridad de red, deben incluir:
a. La encripción de las conexiones involucradas con las operaciones de la CA.
b. Los sitios Web están provistos de certificados SSL.
c. La red está protegida por firewalls y sistemas de detección de intrusos.
d. Los accesos externos a información de bases de datos de la CA están prohibidos.
e. La CA debe controlar la ruta de acceso del usuario desde la Terminal hasta los
servicios.
f. Los componentes de la red local deben mantenerse en un ambiente físicamente
seguro y sus configuraciones deben ser auditadas periódicamente.
g. Los datos sensibles deben encriptarse cuando se intercambian sobre redes
públicas o no confiables.
157
B.19 Administración de Equipo Computacional
Los siguientes requisitos son referentes a los requisitos de los equipos computacionales
que cada Autoridad Certificadora utiliza. Cada uno corresponde a un elemento requerido
actualmente para una CA.
1. El equipo de la Autoridad Certificadora debe usar sistemas operativos que:
a. Requieran autenticación para poder ser accedidos
b. Provean capacidad para mantener bitácoras y registros de seguridad con fines de
auditoría.
c. Cumplan con requerimientos y controles de seguridad.
d. Luego de que la plataforma donde opera el equipo de la Autoridad Certificadora
ha sido aprobada, debe continuar operando bajo los mismos parámetros
aprobados.
2. Las actualizaciones y parches de los sistemas operativos deberían ser aplicados de manera
oportuna y la utilización de programas utilitarios del sistema debería ser restringida al
personal autorizado, y debe estar estrictamente controlado.
3. Los sistemas sensibles de la Autoridad Certificadora requieren un ambiente informático
dedicado y aislado, que implemente el concepto de sede computacional confiable con
procesos de auditorÍa que ejecuten pruebas de seguridad al menos dos veces al año.
4. La Autoridad Certificadora debe mantener controles en los equipos de seguridad
(hardware y software) requeridos para operar en una infraestructura PKI desde el
momento de la compra hasta su instalación, de forma que reduzcan la probabilidad que
cualquiera de sus componentes sea violentado.
158
5. Todo el hardware y software que ha sido identificado para operar las Autoridad
Certificadora debe ser enviado y entregado con métodos que provean una adecuada
cadena de custodia.
6. Los nuevos sistemas o para la expansión de los sistemas existentes, deben especificar los
requisitos de control, seguir procedimientos de prueba de software y control de cambios
para la implementación de software.
7. La Autoridad Certificadora debe mantener controles sobre el acceso a las bibliotecas
fuente de programas.
8. Los Administradores de la Autoridad Certificadora son los responsables de garantizar
que se cumplan los procedimientos de seguridad correctamente. Además de ejecutar
revisiones periódicas para asegurar el cumplimiento de los estándares de implementación
de seguridad.
9. La Autoridad Certificadora debe incluir controles en la gestión de seguridad por medio
de herramientas y procedimientos que verifiquen la adherencia a la configuración de
seguridad de los sistemas operativos y redes.
10. La Autoridad Certificadora debe definir los procedimientos de control del cambio para el
hardware, los componentes de la red y los cambios de configuración del sistema.
11. Cuando los equipos que hospedan los certificados se encuentran en línea, estos se deben
mantener monitoreados y protegidos contra accesos no autorizados. Cuando los equipos
no estén en uso entonces los módulos de hardware criptográfico deben ser removidos y
almacenados.
12. La Autoridad Certificadora debe de mantener un inventario de sus equipos.
13. El equipo debe mantenerse de acuerdo con las instrucciones del fabricante y/u otros
procedimientos documentados, para asegurar su disponibilidad e integridad continua.
159
14. Si la Autoridad Certificadora terceriza la gestión y/o el control de todos o algunos de sus
sistemas de información, redes, ambientes de estaciones de trabajo. los requisitos de
seguridad de la Autoridad Certificadora deberían ser tratados en un contrato previamente
acordado entre las partes.
15. La utilización de programas utilitarios del sistema debería ser restringida al personal
autorizado, y debería ser estrictamente controlado.
16. Los sistemas operativos deberían estar configurados de acuerdo con los estándares de
configuración del sistema operativo de la Autoridad Certificadora y ser revisados
periódicamente.
17. Cuando ocurran cambios en el sistema operativo, los sistemas deberían ser revisados y
probados.
18. Las modificaciones a los paquetes de software deben ser desalentadas y todos los cambios
estrictamente controlados.
19. La compra, uso y modificación del software debe controlarse e inspeccionarse para
protegerse contra posibles canales encubiertos y códigos troyanos. Esto debe incluir la
autenticación del código fuente del software. Estos controles debe aplicarse igualmente
al desarrollo del software externo. Esto debe incluir la acreditación de Criterios Comunes
(“Common Criteria”) según lo definido por la ISO 15408 o similar.
20. Debe existir y seguirse un proceso de autorización gerencial para el uso de nuevas
instalaciones y equipos de procesamiento de la información.
21. Los procedimientos debe requerir que, cuando las computadoras personales y estaciones
de trabajo no se estén utilizando, deben cerrarse las sesiones, bloquearse con contraseña
o utilizar algún otro control similar.
160
22. Los procedimientos deben requerir que el equipo, la información y los programas de
cómputo (software), pertenecientes a la organización, no pueden ser extraídos de las
instalaciones sin autorización.
23. Deben implementarse controles de detección y prevención contra virus y software
malicioso. Deben existir programas de concientización apropiados para empleados.
24. Debe existir y seguirse un procedimiento para reportar el mal funcionamiento del
hardware y software.
25. Debe existir y seguirse un procedimiento para asegurar que las fallas son reportadas y
que se toman las acciones correctivas.
26. Los procedimientos para la gestión de medios de almacenamiento de información
removibles de las computadoras deben requerir lo siguiente:
a. Que el contenido anterior de cualquier medio reutilizable de información que
vaya a ser removido de la organización que ya no sea requerido, sea borrado o
bien destruir el medio de almacenamiento de la información en forma segura;
b. Para toda la información que sea removida de la organización, se requiere una
autorización y se conserva un registro de tales remociones para mantener un rastro
de auditoría;
c. Que todo medio de información sea almacenado en un ambiente adecuado y
seguro, de acuerdo con las especificaciones del fabricante.
27. Los equipos que contengan medios de almacenamiento (es decir, discos duros fijos),
deben examinarse para determinar si contienen alguna información sensible, antes de su
eliminación o reutilización. De ser el caso, estos deben ser destruidos físicamente o
sobrescritos en forma segura, antes de su eliminación o re-utilización.
161
28. Los relojes del sistema de cómputo de la CA deben estar sincronizados para un registro
exacto, como se define en la CP o la CPS, que especifican la fuente de tiempo aceptada.
B.20 Desarrollo de Software
Los siguientes requisitos son referentes a los requisitos de desarrollo de software que
cada Autoridad Certificadora debe tener. Cada uno corresponde a un elemento requerido
actualmente para una CA.
1. La Autoridad Certificadora debe mantener controles que proporcionen una seguridad
razonable de las actividades de desarrollo y mantenimiento de los sistemas de la
Autoridad Certificadora.
2. Las instalaciones para desarrollo y prueba de sistemas deben estar separadas de las
instalaciones operacionales.
3. Se deben establecer criterios de aprobación de nuevos sistemas de información, de
mejoras y nuevas versiones, así como llevar a cabo pruebas de sistemas antes de su
aceptación.
4. Los requisitos de negocio para nuevos sistemas o para la expansión de los sistemas
existentes, deben especificar los requisitos de control.
5. Deben existir y seguirse procedimientos de prueba de software y control de cambios para
la implementación de software en los sistemas en producción, incluyendo un cronograma
para la puesta en marcha de nuevas versiones de software, modificaciones o arreglos de
emergencia.
6. La CA debe tener procedimientos para asegurar que todos los requisitos relevantes
legales, regulatorios y contractuales son explícitamente definidos y documentados para
cada sistema de información.
7. Se debe mantener controles sobre el acceso a las bibliotecas fuente de programas
162
B.21 Documentación
Los siguientes requisitos son referentes a la documentación que cada Autoridad
Certificadora debe proveer. Cada uno corresponde a un elemento requerido actualmente para
una CA.
1. Una Autoridad Certificadora debe documentar sus prácticas de certificación.
2. Una CPS de una Autoridad Certificadora, o algún equivalente, debe soportar cada CP
bajo la cual la Autoridad Certificadora emite o produce certificados.
3. Las prácticas de certificación de la Autoridad Certificadora deben incluir los siguientes
componentes de alto nivel con el nivel de detalle requerido por la Autoridad de Políticas
con referencia a las políticas de los certificados pertinentes:
a. Introducción;
b. Disposiciones generales;
c. Identificación y autenticación;
d. Requisitos de operación;
e. Controles de seguridad físicos, de procedimientos y de personal;
f. Controles de seguridad técnicos;
g. Perfiles de certificado y de CRL;
h. Prácticas de administración.
4. Los controles de la Autoridad Certificadora deben estar descritos en la CPS o en
documentación equivalente.
163
5. La Gerencia de la Autoridad Certificadora debe aprobar, publicar y comunicar a todos
los empleados, un documento de políticas de seguridad de información, que incluya
controles físicos, de personal, procedimentales y técnicos.
6. La política de seguridad de información de una Autoridad Certificadora debe incluir:
a. Una definición de seguridad de la información, sus objetivos generales y su
alcance, y la importancia de la seguridad como un mecanismo que permite
compartir información;
b. Una declaración de propósito gerencial, apoyando las metas y los principios de la
seguridad de la información;
c. Una explicación de las políticas de seguridad, principios, estándares y requisitos
de cumplimiento, que sean de especial importancia para la organización;
d. Una definición de las responsabilidades generales y específicas para la gestión de
la seguridad de la información, incluyendo el reporte de incidentes de seguridad;
e. Las referencias a la documentación que apoya la política.
7. Debe existir un proceso de revisión definido para darle mantenimiento a las políticas de
seguridad de información, que incluya responsabilidades y fechas de revisión.
8. Las modificaciones o enmiendas de las políticas deben documentarse y mantenerse
actualizadas a través de versiones. Las enmiendas deben publicarse en el sitio Web de la
Autoridad Certificadora.
9. La documentación de sistemas debe protegerse de accesos no autorizados.
164
B.22 Gestión de Operaciones
Los siguientes requisitos son referentes a los requisitos para la gestión de las operaciones
que cada Autoridad Certificadora realiza. Cada uno corresponde a un elemento requerido
actualmente para una CA.
1. La Autoridad Certificadora debe contar con políticas y procedimientos formales para el
reporte y atención de incidentes.
2. Los funcionarios ejecutando roles de confianza deben velar por la seguridad de las
instalaciones y la Autoridad Certificadora debe mantener procedimientos para que estos
funcionarios reporten los incidentes.
3. Todos los activos de la Autoridad Certificadora deben tener un encargado/dueño
debidamente identificado, con responsabilidades asignadas para el mantenimiento de los
controles apropiados.
4. La Autoridad Certificadora debe mantener inventarios de sus activos.
5. Los procedimientos operacionales de la Autoridad Certificadora deben estar
documentados y ser mantenidos por cada área funcional.
B.23 Autenticación
Los siguientes requisitos son referentes a los escenarios en los cuáles se debe autenticar
a usuarios que utilizan los sistemas de la Autoridad Certificadora.
1. Si es permitido el acceso remoto a los sistemas de la Autoridad Certificadora, realizado
por los empleados de la Autoridad Certificadora o por sistemas externos, debe requerir
autenticación mutua.
2. Las conexiones hechas por los empleados o sistemas de la Autoridad Certificadora hacia
sistemas computadorizados remotos deben tener autenticación mutua.
165
3. El acceso a los puertos utilizados para diagnóstico debe estar controlado en forma segura.
4. La identificación automática de terminales debe utilizarse para autenticar las conexiones
a equipo portátil y a lugares específicos.
5. El acceso a los sistemas de la Autoridad Certificadora requiere de un proceso protegido
de autenticación.
6. Todo el personal usuario de la Autoridad Certificadora debe tener un identificador único
(ID de usuario), para su uso personal y exclusivo, de modo que las actividades puedan
ser rastreadas hasta el individuo responsable. Cuando se requieren cuentas de grupos o
compartidas, deben implementarse otros controles de monitoreo para mantener la
asignación de responsabilidades en forma individual.
7. Las terminales inactivas que se conectan a los sistemas de la Autoridad Certificadora,
deben requerir reautenticación antes de su uso.
8. Deberían utilizarse restricciones en los tiempos de conexión, para proporcionar una
seguridad adicional, a las aplicaciones de alto riesgo.
9. El personal de la Autoridad Certificadora debe ser exitosamente identificado y
autenticado antes de utilizar las aplicaciones críticas relacionadas con la gestión de los
certificados.
B.24 Seguridad de la Información
Los siguientes requisitos son referentes a la seguridad de la información que cada
Autoridad Certificadora almacena, transmite y manipula. Cada uno corresponde a un
elemento requerido actualmente para una CA.
1. La Autoridad Certificadora debe establecer controles para prevenir que personas no
autorizadas agreguen, eliminen o modifiquen información de los repositorios.
166
2. La Autoridad Certificadora no debe publicar información de los certificados emitidos en
los repositorios de acceso público.
3. La Autoridad Certificadora no debe custodiar llaves de suscriptores para ningún
certificado cuyo propósito sea de firma digital, únicamente se mantienen respaldos de sus
propias llaves privadas de acuerdo con el Plan de Continuidad de Negocio.
4. Para los efectos de Plan de Continuidad de Negocio, las llaves privadas de la Autoridad
Certificadora deben estar en custodia y respaldadas bajo estrictas normas de seguridad, y
almacenadas en dispositivos criptográficos FIPS 140–2 nivel 3, que garanticen la no
divulgación de las llaves.
5. La Autoridad Certificadora debe asegurar el adecuado manejo y protección de los medios
de almacenamiento de información, que contengan datos críticos o sensitivos del sistema,
contra daños accidentales (agua, fuego, electromagnetismo) y debe impedir, detectar y
prevenir su uso no autorizado, acceso o su divulgación.
6. La Autoridad Certificadora debe implementar controles para la eliminación de residuos
(papel, medios, equipos y cualquier otro desecho) con el fin de prevenir el uso no
autorizado, el acceso o divulgación de información privada y confidencial contenida en
los desechos.
7. La Autoridad Certificadora debe establecer procedimientos para asegurar que la
información personal esté protegida de conformidad con la legislación pertinente.
8. Las gerencias de más alto rango y/o un comité de alto nivel de la gestión de seguridad de
información, deben tener la responsabilidad de asegurar que existe una dirección clara y
apoyo gerencial para gestionar los riesgos efectivamente dentro de la Autoridad
Certificadora.
167
9. Dentro de la Autoridad Certificadora debe existir un grupo de control o un comité de
seguridad para coordinar la implementación de la seguridad de la información y la gestión
de los riesgos.
10. La Autoridad Certificadora debe definir claramente, las responsabilidades para la
protección de los activos individuales y para llevar a cabo procesos específicos de
seguridad.
11. La documentación de los sistemas de la Autoridad Certificadora deben protegerse de
accesos no autorizados.
12. La Autoridad Certificadora debe implementar un esquema para la clasificación de la
información y los controles de protección aplicables para esta información, basados en
las necesidades de negocio e impactos comerciales asociados con tales necesidades.
13. Se deberían definir procedimientos para asegurar que el etiquetado y la manipulación de
información, se lleven a cabo de acuerdo con el esquema de clasificación de la Autoridad
Certificadora.
14. Se debe guardar bajo llave la información de negocio sensible o crítica, cuando no sea
requerida y cuando las instalaciones de la Autoridad Certificadora estén desocupadas (sin
ocupación humana).
15. Deben existir y seguirse procedimientos para el manejo y almacenamiento de la
información, para protegerla de divulgación no autorizada o mal uso.
16. Los requisitos de negocio para el control de acceso, deberían estar definidos y
documentados en una política de control de acceso, la cual debería incluir al menos lo
siguiente:
a. Roles y permisos de acceso correspondientes;
b. Procesos de identificación y autenticación para cada usuario;
168
c. La segregación de deberes;
d. El número de personas (“key share holders”) requeridas para ejecutar operaciones
específicas de la CA (es decir, regla “m de n”, dónde “m” representa el número
de partes de la llave requeridos para ejecutar una operación y “n” representa el
número total de partes de la llave).
17. El acceso a la información y a las funciones del sistema de aplicación debería ser
restringido, de acuerdo con las políticas de control de acceso de la CA.
18. La política de seguridad de la información debe abordar lo siguiente:
a. La información que debe mantenerse confidencial por la CA o RA;
b. La información que no es considerada confidencial;
c. La política de entrega de información a las autoridades judiciales;
d. La información que puede ser revelada como parte de un proceso civil;
e. Las condiciones sobre las cuales la información puede ser revelada con el
consentimiento del suscriptor;
f. Cualquier otra circunstancia bajo la cual la información confidencial puede ser
revelada.
19. Cuando un contrato de trabajo es concluido, deberían ejecutarse acciones apropiadas y
oportunas, de manera que los controles (ejemplo, controles de acceso), no sean
deteriorados.
B.25 Seguridad Física y Ambiental
Los siguientes requisitos son referentes a los requisitos de seguridad física y ambiental
que cada Autoridad Certificadora debe tener. Cada uno corresponde a un elemento requerido
actualmente para una CA.
169
1. El equipo de la Autoridad Certificadora debe protegerse contra fallas en el fluido eléctrico
corriente y otras anomalías en la energía.
2. Las instalaciones de la Autoridad Certificadora deben estar equipadas con sistemas de
energía primario y de respaldo para asegurar continuidad del fluido eléctrico.
3. Las instalaciones deben contar con sistemas de aire acondicionado redundantes. El
equipo instalado para climatizar el recinto, debe ser capaz de controlar la humedad
relativa del mismo.
4. Las instalaciones de la Autoridad Certificadora deben ser construidas y equipadas, y
contar con procedimientos implementados para prevenir inundaciones y otros daños por
exposición al agua.
5. Las instalaciones de la Autoridad Certificadora deben contar con procedimientos
implementados para la prevención y protección al fuego. Además de ser construidas y
equipadas para prevenir, detectar y suprimir incendios o daños producidos por la
exposición a llamas o humo.
6. La protección física debería lograrse por medio de la creación de un perímetro de
seguridad restringido (ejemplo, barreras físicas y lógicas). Las instalaciones donde se
fabrican los certificados de la Autoridad Certificadora deben protegerse con su propio y
único perímetro físico.
7. El perímetro del edificio o sitio donde se encuentran las instalaciones de fabricación de
certificados de la CA, debe tener el mínimo número de puntos de acceso y estos deberían
ser debidamente controlados.
8. Debe existir un área de recepción controlada por personal u otros medios de control de
acceso físico para restringir el acceso al edificio o al sitio de operaciones de la Autoridad
Certificadora, únicamente al personal autorizado.
170
9. Se debe colocar barreras físicas (ejemplo, paredes sólidas que se extiendan desde el piso
“real” al cielo raso “real”) para prevenir el ingreso no autorizado y la contaminación
ambiental a las instalaciones de producción de certificados de la CA.
10. Se debe colocar barreras (por ejemplo: Cajas de Faraday) para prevenir emisiones de
radiación electromagnética en las operaciones de la Autoridad Certificadora raíz,
(ejemplo, generación de llaves y de certificados de CA) y donde las políticas de
certificado lo dicten.
11. Las puertas contra incendio que se ubiquen en el perímetro de seguridad alrededor de las
instalaciones operacionales de la CA, deben tener alarmas y cumplir con las regulaciones
locales contra incendios.
12. Se debe instalar y probar regularmente, un sistema de detección de intrusos, que cubra
todas las puertas externas del edificio donde se encuentran las instalaciones operacionales
de la Autoridad Certificadora.
13. Cuando las instalaciones operacionales de la Autoridad Certificadora estén desocupadas,
deberían estar cerradas con llave y con las alarmas debidamente activadas.
14. Todo el personal debe portar una identificación visible. Los empleados deben ser instados
a confrontar a cualquiera que no porte la identificación visible.
15. El acceso a las instalaciones operacionales de la Autoridad Certificadora debería ser
controlado y restringido a personas autorizadas, utilizando controles de autenticación.
16. Todo el personal que entra y sale de las instalaciones operacionales debe registrarse (es
decir, se mantiene en forma segura un registro de auditoría de todos los accesos).
17. Los visitantes a las instalaciones operacionales de la Autoridad Certificadora deben ser
escoltados y registrarse la fecha y hora de entrada y salida.
171
18. Al personal de servicios de soporte tercerizado debe concedérsele acceso restringido a
las instalaciones operacionales de la CA seguras, solamente cuando sea requerido y dicho
acceso debería ser autorizado y escoltado.
19. Los derechos de acceso a las instalaciones de la Autoridad Certificadora deberían
revisarse y actualizarse regularmente.
20. El equipo debería ubicarse o protegerse de tal forma que se reduzcan los riesgos de
amenazas ambientales y peligros, así como de oportunidades de accesos no autorizados.
21. El cableado eléctrico y de telecomunicaciones, que conduce datos o servicios de respaldo
de la Autoridad Certificadora, debería ser protegido contra intercepción o daño.
22. Las instalaciones de la Autoridad Certificadora deben contar con al menos cuatro
perímetros de seguridad física (área de recepción, área de servicios de soporte–
climatización, energía, comunicaciones, etc.–, área de operación de la Autoridad
Certificadora, área de custodia de material criptográfico). Un perímetro es una barrera o
entrada que provee un control de acceso para individuos y requiere una respuesta positiva
para proceder a ingresar a la siguiente área. Cada perímetro sucesivo se encuentra más
restringido, con controles de acceso más estrictos.
23. Las instalaciones donde se crean los certificados de la Autoridad Certificadora se deben
proteger con su propio y único perímetro físico, y las barreras físicas (paredes, barrotes)
deben ser sólidas, extendiéndose desde el piso real al cielo raso real. Asimismo, estas
barreras deben prevenir las emisiones de radiación electromagnética.
B.26 Acceso a las Instalaciones
Los siguientes requisitos son referentes al acceso de personal autorizado y no autorizado
a los equipos críticos que cada Autoridad Certificadora utiliza.
172
1. Las operaciones de la Autoridad Certificadora deben estar dentro de un ambiente de
protección física que impida y prevenga usos o accesos no autorizados o divulgación de
información sensible.
2. Cuando las instalaciones operacionales de la Autoridad Certificadora estén desocupadas,
deben estar cerradas con llave y con las alarmas debidamente activadas.
3. Los perímetros deben ser auditados y controlados para verificar que solo puede tener
acceso el personal autorizado debidamente identificado.
4. Los derechos de acceso a las instalaciones de la Autoridad Certificadora deben revisarse
y actualizarse regularmente, al menos cada seis meses o cuando se presente movimiento
en el personal relacionado con labores de operación de la Autoridad Certificadora.
5. Los visitantes o personal de servicio de soporte tercerizado que requiera acceso a las
instalaciones operacionales de la Autoridad Certificadora, deben ser escoltados y
registrarse el responsable de autorizar el acceso, la fecha y hora de entrada y salida.
6. Los arreglos que comprendan el acceso de un tercero a las instalaciones y sistemas de la
Autoridad Certificadora, deberían basarse en un contrato formal, que contenga todos los
requisitos de seguridad necesarios.
7. Si hubiese una necesidad comercial para la Autoridad Certificadora de permitir el acceso
a un tercero a sus instalaciones y sistemas, debería ejecutarse una evaluación de riesgos
para determinar las implicaciones de seguridad y los requisitos de control específicos.
B.27 Gestión de la continuidad del negocio
Los siguientes requisitos son referentes a los requisitos de gestión de continuidad del
negocio que cada Autoridad Certificadora debe cumplir. Cada uno corresponde a un elemento
requerido actualmente para una CA.
173
1. La Autoridad Certificadora debe mantener controles para brindar una seguridad
razonable de que la continuidad de las operaciones se mantenga en caso de compromiso
de las llaves privadas de la Autoridad Certificadora.
2. Los planes de continuidad del negocio de la Autoridad Certificadora deben referirse al
compromiso o sospecha de compromiso de las llaves privadas de la Autoridad
Certificadora como un desastre.
3. En caso de que la llave de la Autoridad Certificadora se haya comprometido, el superior
de la Autoridad Certificadora deberá revocar el certificado de Autoridad Certificadora, y
la información de la revocación debe publicarse inmediatamente.
4. La Autoridad Certificadora debe contar con un proceso administrativo para desarrollar,
probar, implementar y mantener sus planes de continuidad del negocio.
5. La Autoridad Certificadora debe desarrollar, probar, mantener e implementar un plan de
recuperación de desastres destinado a mitigar los efectos de cualquier desastre natural o
producido por el hombre. Los planes de recuperación de desastres se enfocan en la
restauración de los servicios de sistemas de información y de las funciones esenciales del
negocio.
6. Los dispositivos criptográficos utilizados para el almacenamiento del respaldo de las
llaves privadas de la Autoridad Certificadora deben ser guardados de forma segura, en
un sitio alterno, para que sean recuperados en el caso de un desastre en el sitio primario.
7. Las partes de la clave secreta o los componentes necesarios para usar y gestionar los
dispositivos criptográficos de recuperación de desastres, deben estar también guardados
con seguridad en una ubicación fuera del sitio primario.
8. El sitio alterno debe contar con protecciones de seguridad física equivalentes al sitio
principal.
174
9. El sitio alterno, debe tener la capacidad de restaurar o recobrar operaciones esenciales
dentro de las veinticuatro horas siguientes al desastre, con al menos soporte para las
siguientes funciones: revocación de certificados y publicación de información de
revocación.
10. Si la Autoridad Certificadora no puede ser reestablecida dentro de una semana, entonces
su llave se reporta como comprometida y todos sus certificados son revocados.
11. Se debe monitorear y evaluar las demandas de capacidad y hacer proyecciones de los
requisitos futuros de capacidad, para asegurar que esté disponible el adecuado poder de
procesamiento y de almacenamiento.
12. Los planes de continuidad del negocio de la CA deben incluir procesos de recuperación
de desastres para todos los componentes críticos del sistema de la CA, incluyendo el
hardware, software y llaves, en el caso de falla de uno o más de estos componentes.
13. En caso de compromiso o sospecha de compromiso de la llave privada de firma de la CA,
deben existir procedimientos de recuperación de desastre que incluyan la revocación y
re-emisión de todos los certificados que fueron firmados con la llave privada de la CA.
14. Los procedimientos de recuperación utilizados en caso de compromiso de la llave privada
de la CA, deben incluir las siguientes acciones:
a. ¿Cómo asegurar el uso de la llave en el ambiente que es restablecida?
b. ¿Cómo se revoca la vieja llave pública de la CA?
c. Los procedimientos de notificación para las partes afectadas (ejemplo las CA
afectadas, repositorios, suscriptores, los CVSP, etc.)
d. ¿Cómo se proporciona la nueva llave pública de la CA a las entidades finales y
partes que confíanjunto con el mecanismo para su autenticación?
e. ¿Cómo se re-certifican las llaves públicas de los suscriptores?
175
15. En caso de compromiso de la llave privada, el plan de continuidad del negocio de la CA
debe establecer quién es notificado y qué acciones son tomadas con los sistemas de
hardware y software, llaves simétricas y asimétricas, firmas generadas previamente y
datos encriptados.
16. La CA debe tener un plan de continuidad del negocio para mantener o restaurar sus
operaciones de una manera oportuna después de una interrupción, o falla de los procesos
críticos. El plan de continuidad del negocio de la CA debería contemplar lo siguiente:
a. Las condiciones para la activación de los planes;
b. Procedimientos administrativos de emergencia;
c. Procedimientos operativos de emergencia (“fallback procedures”);
d. Procedimientos de reanudación o recuperación;
e. Un cronograma de mantenimiento para el plan;
f. Requisitos de concientización y educación;
g. Las responsabilidades de los individuos;
h. Tiempo de recuperación meta (“recovery time objective”, RTO);
i. Pruebas regulares de los planes de contingencia.
17. Los planes de continuidad del negocio deben mantenerse con revisiones regulares y
actualizaciones para asegurar su continua efectividad.
18. Los planes de continuidad del negocio deben probarse regularmente para asegurar que se
encuentran actualizados y son efectivos.
19. El plan de continuidad del negocio de la CA debe considerar las técnicas de replicación
de llave, tales como las descritas en el Anexo J de la ISO 15782-1:2003.
176
B.28 Bitácoras y Registros de Auditorías
Los siguientes requisitos son referentes a las bitácoras y registros de auditorías que cada
Autoridad Certificadora debe tener. Cada uno corresponde a un elemento requerido
actualmente para una CA.
1. La Autoridad Certificadora debe mantener controles para proveer una seguridad
razonable de que:
a. Los eventos relacionados con el ambiente de operación de la CA, la gestión
de las llaves y los certificados, son registrados exacta y apropiadamente;
b. Se mantiene la confidencialidad y la integridad de los registros de auditoría
vigentes y archivados;
c. Los registros de auditoría son archivados completa y confidencialmente;
d. Los registros de auditoría son revisados periódicamente por personal
autorizado.
2. La Autoridad Certificadora debe mantener copias de respaldo de todos los registros
auditados.
3. Cuando un evento es almacenado por la bitácora, no se requiere notificar al causante
de dicho evento.
4. El personal de la Autoridad Certificadora emisora con el rol de auditor debe realizar
al menos tres revisiones por año de las bitácoras de auditoría, sin necesidad de ser
avisadas; mientras que la Autoridad Certificadora Raíz debe realizar al menos una
revisión anual de las bitácoras.
5. Las bitácoras de auditoría deben ser revisadas en respuesta a una alerta, por
irregularidades o incidentes dentro de los sistemas de la Autoridad Certificadora.
177
6. El procesamiento de la bitácora de auditoría consiste en una revisión de las bitácoras
y la documentación de los motivos para los eventos significativos, y todas las
acciones deben ser documentadas.
7. Las bitácoras de auditorías actuales y archivadas deben ser recuperadas solamente
por personal autorizado, ya sea por razones válidas del negocio o por seguridad.
8. Las bitácoras de auditoría deben ser mantenidas en el sistema por al menos dos meses
posterior a su procesamiento y deber ser archivadas
9. Las bitácoras de auditorías actuales o archivadas deben mantenerse de forma que se
prevenga su revelación, modificación, destrucción no autorizada o cualquier otra
intromisión.
10. Las bitácoras de auditoría no deben registrar las llaves privadas de ninguna forma y
los relojes del sistema de cómputo de la CA deben estar sincronizados con el servicio
de tiempo UTC–6 para un registro exacto de los eventos.
11. La Autoridad Certificadora debe registrar los tipos de eventos que se presentan en sus
operaciones según lo requerido por la ley y los requerimientos de la política de
certificado. La CA debe mantener las bitácoras manuales o automáticas, indicando
para cada evento la entidad que lo causa, la fecha y hora del mismo. La CA debe
registrar los eventos relacionados con:
a. La gestión del ciclo de vida de las llaves de la CA;
b. La gestión del ciclo de vida del dispositivo criptográfico;
c. La gestión del ciclo de vida del sujeto de certificado;
d. La información de solicitud de certificados;
e. La gestión del ciclo de vida del certificado;
178
f. Los eventos sensibles de seguridad;
12. La Autoridad Certificadora debe almacenar los registros para establecer la validez de
una firma y de la operación propia de la infraestructura PKI. Se deben archivar los
siguientes datos:
a. Durante la inicialización del sistema de la CA:
i. La acreditación de la CA (si es necesaria);
ii. El CP y el CPS;
iii. Cualquier acuerdo contractual para establecer los límites de la CA;
iv. La configuración del sistema.
b. Durante la operación de la CA:
i. Modificaciones o actualizaciones de cualquiera de los ítems
anteriores;
ii. Solicitudes de certificados o de revocación;
iii. Documentación para autenticar la identidad del suscriptor;
iv. Documentación de recepción y aceptación del certificado;
v. Documentación de recepción de dispositivos de almacenamiento de
llaves;
vi. Todos los certificados y CRLs (información de revocación) tanto
emitidos o publicados;
vii. Bitácoras de auditoría;
viii. Otros datos o aplicaciones para verificar el contenido de los archivos;
179
c. Todos los trabajos comunicados o relacionados a políticas, otras CA y
cumplimiento de auditoría.
13. La Autoridad Certificadora debe mantener todos los archivos por un periodo de al
menos diez años. Además debe mantener los controles para que los archivos puedan
ser leídos durante el periodo de retención definido.
14. Los archivos de la bitácora no deben modificarse o eliminarse por alguna operación
no autorizada del equipo de la Autoridad Certificadora. La CA debe mantener la lista
de personas autorizadas a mover los registros a otros medios.
15. Los medios de almacenamientos deben estar guardados en instalaciones seguras, los
registros deben ser etiquetados con un nombre distintivo, la fecha y hora de
almacenamiento y la clasificación del tipo de información.
16. Los sistemas de archivos de la CA son internos al ámbito de sus operaciones y deben
conservar las pistas de auditoría.
17. Además de lo indicado por una posible estipulación regulatoria, debe ejecutarse una
evaluación de riesgo, para determinar el período apropiado para la retención de las
bitácoras de auditoría.
18. La Autoridad Certificadora debe utilizar firmas digitales para proteger la integridad
de las bitácoras en donde aplique o sea requerido para satisfacer requisitos legales.
19. La llave privada utilizada para firmar las bitácoras de auditoría no debe ser utilizada
para ningún otro propósito. Esto debe aplicarse igualmente a una llave secreta
simétrica utilizada con un mecanismo “Message Authentication Code” (MAC)
simétrico.
20. Todos los registros en la bitácora deben incluir lo siguiente:
a. El día y la hora del registro;
180
b. El número de serie o de secuencia del registro (para registros de bitácora
automáticos);
c. Tipo de registro;
d. La fuente del registro (ejemplo, terminal, puerto, ubicación, cliente, etc.);
e. La identidad de la entidad que hace el registro en la bitácora.
21. La CA debe registrar los siguientes eventos relacionados con la gestión del ciclo de
vida de las llave de la CA y de sujeto (si aplica):
a. La generación de llaves de la CA;
b. La instalación de las llaves criptográficas manuales y su resultado (con la
identidad del operador);
c. El respaldo de la llaves de la CA;
d. El almacenamiento de las llaves de la CA;
e. La recuperación de la llave de la CA;
f. Las actividades de custodia de las llaves de la CA (si aplica);
g. El uso de las llaves de la CA;
h. El archivado de las llaves de la CA;
i. El retiro de servicio del material relacionado con las llaves (“keying
material”);
j. La destrucción de las llaves de la CA;
k. La identidad de la entidad que autoriza una gestión de operación de llaves;
181
l. La identidad de las entidades que manipulan cualquier material relacionado
con las llaves (“keying material”), tales como componentes de llave, o llaves
almacenadas en dispositivos o medios portátiles;
m. La custodia de llaves y de dispositivos o medios de almacenamiento de llaves;
n. El compromiso de una llave privada.
22. La CA debe registrar los siguientes eventos relacionados con la gestión del ciclo de
vida del dispositivo criptográfico:
a. La recepción e instalación del dispositivo;
b. La colocación o remoción de un dispositivo de su lugar de almacenamiento;
c. La activación y el uso del dispositivo;
d. La desinstalación del dispositivo;
e. La designación de un dispositivo para servicio y reparación;
f. El retiro permanente del dispositivo.
23. Si la CA provee servicios de gestión de llaves de sujeto, ésta debe registrar los
siguientes eventos relacionados con la gestión del ciclo de vida de llaves de sujeto:
a. La generación de la llave;
b. La distribución de la llave (si aplica);
c. El respaldo de la llave (si aplica);
d. La custodia de la llave (si aplica);
e. El almacenamiento de la llave;
f. La recuperación de la llave (si aplica);
182
g. El archivado de la llave (si aplica);
h. La destrucción de la llave;
i. La identidad de la entidad que autoriza una gestión de operación con las
llaves;
j. El compromiso de la llave.
24. La CA debe registrar (o solicitar que la RA registre) la siguiente información en la
solicitud del certificado:
a. El método de identificación utilizado y la información utilizada para satisfacer
los requisitos de “Conozca a su Cliente”;
b. El registro de datos o números de identificación únicos de documentos de
identificación o una combinación de estos (ejemplo, número de licencia de
conducir del solicitante), si aplica;
c. El lugar de archivo de las copias de solicitudes y copias de los documentos de
identificación;
d. La identificación de la entidad que acepta la solicitud;
e. El método utilizado para validar los documentos de identificación, si hay
alguno;
f. El nombre de la CA que recibe o de la RA que presenta la solicitud, si aplica;
g. La aceptación del sujeto del contrato de suscriptor;
h. El consentimiento del suscriptor para permitir que la CA mantenga registros
con datos personales, traslade esta información a terceros específicos, y
publique los certificados.
183
i. Todo lo anterior cuando se requiera y de conformidad con la legislación
aplicable.
25. La CA debe registrar los siguientes eventos relacionados con la gestión del ciclo de
vida del certificado:
a. La recepción de solicitudes para certificado(s) – incluyendo solicitudes
iniciales de certificado, solicitudes de renovación y solicitudes de reemisión
de llaves;
b. La presentación de llaves públicas para certificación;
c. Cambios de afiliación de una entidad;
d. La generación de certificados;
e. La distribución de la llave pública de la CA;
f. Las solicitudes de revocación de certificado;
g. La revocación de certificado;
h. Las solicitudes de suspensión de certificado (si aplica);
i. La suspensión y reactivación del certificado;
j. La generación y emisión de las listas de revocación de certificados.
26. La CA debe registrar los siguientes eventos sensibles de seguridad:
a. Lectura y escritura de registros o archivos sensibles de seguridad, incluyendo
las mismas bitácoras de auditoría;
b. Las acciones tomadas contra los datos sensibles de seguridad.
c. Los cambios de perfil de seguridad;
184
d. El uso de mecanismos de identificación y autenticación, tanto exitosos como
infructuosos (incluyendo múltiples intentos de autenticación fallida);
e. Las transacciones no financieras de seguridad sensible (ejemplo, cambios en
la cuenta, nombre, dirección, etc.);
f. Las caídas del sistema, fallas del hardware y otras anomalías;
g. Las acciones tomadas por individuos con roles de confianza, operadores de
computadora, administradores del sistema, y oficiales de seguridad de
sistemas;
h. Cambios en la afiliación de una entidad;
i. Las decisiones de pasar por alto los procedimientos o procesos de encriptación
o autenticación;
j. El acceso a los sistemas de la CA o cualquier componente de estos.
27. Las bitácoras de auditorías actuales o archivadas, deben mantenerse de forma que se
prevenga su modificación o destrucción no autorizada.
28. La CA debe archivar los datos de bitácoras de auditoría periódicamente.
29. La CA debe mantener las bitácoras de auditoría archivadas en un sitio alterno seguro,
por un período determinado, definido por la evaluación de riesgo y los requisitos
legales.
30. La oficina de tarjetas o la CA (o RA) deben registrar la preparación y personalización
de la ICC en una bitácora de auditoría.
B.29 Procesos de Auditoría
Los siguientes requisitos son referentes a los procesos de auditoría que debe realizar una
Autoridad Certificadora del SNCD.
185
1. Las operaciones de la CA deben estar sujetas a revisiones periódicas para
asegurar el cumplimiento con lo estipulado en su CPS.
2. Los sistemas de la CA deben ser inspeccionados periódicamente para asegurar
que cumplen con los estándares de implementación de seguridad.
3. Procedimientos para monitorear el uso de los sistemas de la CA deben ser
establecidos, y los resultados de las actividades de monitoreo deben ser revisadas
regularmente. Se deben implementar mecanismos de alerta para detectar accesos
no autorizados.
4. Las bitácoras de auditoría deben ser revisadas de acuerdo con las prácticas
establecidas en la CPS.
5. La revisión de las bitácoras de auditorías actuales y archivadas deben incluir una
validación de la integridad de las mismas, y la identificación y seguimiento de
actividades poco comunes, no autorizadas o sospechosas. Ejemplos de
condiciones que requieren análisis y una posible acción, incluyen la saturación
inusual de los recursos del sistema, un incremento repentino e inesperado en el
volumen y accesos en horarios inusuales o desde lugares inusitados.
6. El rendimiento del repositorio o del mecanismo de distribución alternativo de la
CA, debe ser monitoreado y gestionado;
7. La CA debe tener procedimientos para ejecutar acciones correctivas para las
deficiencias identificadas tanto en las evaluaciones externas como en las
auditorías internas.
8. Los procesos de auditoría de seguridad deben ejecutarse independientemente y
no deben, de ninguna forma, estar bajo el control de la CA, los procesos de
auditoría deben ser invocados al iniciar el equipo y terminarlos solo cuando el
sistema es apagado. En caso de que el sistema automatizado de auditoría falle,
186
la operación de la CA debe cesar hasta que las capacidades de auditoría puedan
ser reestablecidas.
9. La CA y el personal operativo deben estar vigilantes de intentos para violar la
integridad del sistema de generación de certificados, incluyendo equipo,
localización física y personal. Las bitácoras deben ser revisadas por un auditor
de seguridad para los eventos que poseen acciones repetitivas, solicitudes para
información privilegiada, intentos de acceso al sistema de archivos y respuestas
no autenticadas.
10. Los equipos donde se ejecutan las operaciones de la CA emisora deben
someterse a análisis semestrales de vulnerabilidades.
B.30 Conservación de Registros
Los siguientes requisitos son referentes a la conservación de registros por parte de una
Autoridad Certificadora. Cada uno corresponde a un elemento requerido actualmente para
una CA.
1. 401 La Autoridad Certificadora debe conservar la información y registros relativos a los
certificados que emitan, durante no menos de diez años contados a partir de su expiración
o revocación. En caso de cese de actividades, la información y registros respectivos
deberán ser remitidos a la DCFD, quien dispondrá lo relativo a su adecuada conservación
y consulta.
B.31 Terminación de una CA
Los siguientes requisitos son referentes al proceso de terminación que debe realizar una
Autoridad Certificadora del SNCD.
187
1. 402 Cada CA o RA debe desarrollar un plan de terminación que minimice el impacto y
la interrupción del servicio provisto a los clientes, suscriptores y partes que confían.
Dicho plan debe darle tratamiento al menos a los siguientes puntos:
a. Notificación a las partes afectadas asumiendo el costo de la misma.
b. Procedimiento de revocación del certificados (de la CA, CA subordinadas, los
utilizados en RA para sus operaciones, suscriptores, etc. según sea el caso).
c. La preservación de toda la información en concordancia con este CP y la
normativa aplicable.
d. La continuación de los servicios de validación de los certificados y de soporte a
los suscriptores.
e. Procedimientos para la eliminación de las llaves privadas y del hardware que las
contiene.
f. Disposiciones para la transición de los servicios a una CA sucesora.
B.32 Certificaciones & Estándares
Los requisitos que se muestran a continuación son referentes a las certificaciones tanto
técnicas como administrativas que debe tener una Autoridad Certificadora para funcionar
dentro del SNCD. Cada uno corresponde a un elemento requerido actualmente para una CA.
1. La Autoridad Certificadora debe, para obtener la condición de certificador registrado,
poseer idoneidad técnica y administrativa, que serán valoradas por el ECA, de
conformidad con los lineamientos técnicos establecidos en las Normas INTE-ISO/IEC
17021 e INTE/ISO 21188 versión vigente, las políticas fijadas por la DCFD y los
restantes requisitos que esa dependencia establezca, de acuerdo con su normativa
específica.
188
2. Las Autoridades Certificadores dentro de la Jerarquía Nacional de Certificadores
Registrados deben cumplir con las políticas nacionales y con los estándares
determinados, a saber:
a. Ley y reglamento de firma digital,
b. Políticas de la raíz para los certificados de:
c. Firma digital y autenticación de persona física.
d. Sello electrónico y autenticación de agente electrónico.
e. INTE/ISO 21188: “Infraestructura de llave pública para servicios financieros.
Estructura de prácticas y políticas”.
f. RFC 3647: “Internet X.509 Public Key Infrastructure. Certificate Policy and
Certification Practices Framework”.
3. La Autoridad Certificadora debe ajustarse al cumplimiento de las auditorías realizadas
por el ECA, las cuales permiten establecer una confianza razonable en el sistema de firma
digital.
4. La Autoridad Certificadora debe implementar un programa de auditorías internas para la
verificación de su sistema de gestión. Dicho programa de auditorías debe estar basado en
la INTE–ISO/IEC 19011 “Directrices para la auditoría de sistemas de gestión de la
calidad y/o ambiental”.
B.33 Formato Certificados
Los siguientes requisitos son referentes al formato de los certificados generados por
una Autoridad Certificadora del SNCD.
1. Los certificados digitales deben cumplir con:
189
a. Estándar X.509 versión 3.
b. RFC3280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
c. RFC 3039 “Internet X.509 Public Key Infrastructure Qualified Certificates
Profile.
d. ISO 3166–1 “Códigos para la representación de los nombres de los países y sus
subdivisiones. Parte 1: Códigos de los países”.
2. La extensión “subjectAltName” es opcional y solamente se puede usar para certificados
de agente electrónico de persona jurídica. En caso de ser utilizada, el uso de esta extensión
debe ser “NO crítico” y únicamente está permitido el uso del nombre DNS.
3. Para el caso de las CAs emisoras se debe colocar el campo “PathLenghtConstraint” con
un valor de 0, para indicar que la CA no permite más sub–niveles en la ruta del
certificado. Es un campo crítico.
4. El método para la generación del identificador está basado en la llave pública de la CA
emisora del certificado, de acuerdo a lo descrito por el RFC 3280 “Internet X.509 Public
Key Infraestructura Certificate and CRL Profile”. La extensión NO es crítica.
5. Los certificados generados dentro de la jerarquía nacional de certificadores registrados
deben usar uno de los siguientes algoritmos:
a. sha – 1WithRSAEncryption OID = iso(1) member–body(2) us(840)
rsadsi(113549) pkcs(1) pkcs–1(1) 5
b. sha256WithRSAEncryption OID = iso(1) member–body(2) us(840)
rsadsi(113549) pkcs(1) pkcs–1(1) 11
c. El algoritmo SHA–1 se mantiene como algoritmo válido para soportar los
certificados que sean emitidos por CAs constituidas al amparo de versiones
anteriores de la política, sin embargo toda CA nueva o renovada a partir de la
190
emisión de la presente política deberá emitir certificados utilizando el algoritmo
SHA256.
6. Los certificados de suscriptores generalmente deben incluir el URL donde se encuentran
los términos del uso de los certificados y los acuerdos entre las partes.
7. Los nombres se escriben en mayúsculas y sin tildes, únicamente se debe aceptar el
carácter Ñ como un caso especial para los nombres de personas físicas y jurídicas. El
código de país es de dos caracteres y se asigna de acuerdo al estándar ISO 3166–1
“Códigos para la representación de los nombres de los países y sus subdivisiones. Parte
1: Códigos de los países”.
B.34 Respaldos de Información
Los siguientes requisitos son referentes a los respaldos de información debe realizar una
Autoridad Certificadora del SNCD.
1. La CA debe mantener respaldos de los datos críticos del sistema y de cualquier otra
información sensitiva, incluyendo los datos de auditoría, en una instalación segura fuera
del sitio principal.
2. La CA debe mantener procedimientos adecuados de respaldo de archivos (físicos y
electrónicos), tanto en el sitio principal como en el alterno, que aseguren la disponibilidad
de los mismos, de acuerdo a un análisis de riesgos determinado por los factores de
operación de la CA.
3. Solamente el personal de confianza autorizado está habilitado para obtener acceso al
archivo. La CA debe realizar pruebas de restauración de la información archivada al
menos una vez al año. La integridad de la información debe ser verificada cuando es
restaurada.