UNIDAD III.

- CERTIFICADOS Y FIRMAS DIGITALES

3.1. Distribucin de claves.
3.2. Certificacin.
3.3. Componentes de una PKI.
3.4. Arquitecturas PKI.
3.5. Polticas y prcticas de certificacin.
3.6. Gestin de una PKI.
3.7. Estndares y protocolos de certificacin.
3.8. Ejemplo de un protocolo de seguridad: HTTPS.
3.9. SSL, TSL, SSH.
3.10. Prueba con un generador de certificados gratuito, libre y en lnea.

3.1 DISTRIBUCIN DE CLAVES

Distribucin manual
El envo de la clave no es por la lnea de comunicacin por la cual se mandan los
mensajes cifrados, sino que se utilizan otros mtodos, por ejemplo:

Realizando la suma mdulo dos de varias claves enviadas por distintos medios
por ejemplo: carta certificada + va telefnica + fax.

Utilizando un inyector de claves; ste es un pequeo aparato en donde se

almacena una clave la cual puede ser transferida una o ms veces a un equipo,
tiene un contador que registra el nmero de veces que la clave es transferida por
lo que se puede controlar el nmero de instalaciones de la clave en otros equipos,
el inyector debe ser trasportado por medio de una tercera entidad de gran
confianza y de preferencia que no sea experto en el tema.
Este tipo de mtodos dejan de ser prcticos cuando la cantidad de claves que se
deben mandar o las distancias que se deban recorrer para realizar la entrega son
muy grandes, lo cual hace que este mtodo sea lento, caro y poco seguro.
Distribucin basada en centro

Las dos entidades interesadas en intercambiar datos tienen una conexin cifrada
con una tercera entidad de confianza, esta tercera entidad es la encargada de
entregar la clave a travs de los enlaces cifrados a las otras dos entidades.
La figura 3.3.6 muestra diversos esquemas de la distribucin basada en centro.

Figura 3.3.6

Distribucin basada en centro

El modelo PULL requiere que el emisor A obtenga la clave de sesin del KDC,
antes de comunicarse con B.
1. A solicita una clave de sesin al KDC.
2. El KDC enva a A la clave de sesin que utilizar para comunicarse con B y un
paquete cifrado para que A lo entregue a B, dicho paquete est cifrado con la
clave que slo conocen B y el KDC y contiene la clave de sesin con la que B se
comunicar con A as como un identificador de A.
3. A enva a B el paquete que le envo el KDC para B.
El modelo PUSH requiere que A primero contacte a B y despus B debe obtener
la clave de sesin del KDC.
1. A se comunica con B y le hace saber que requiere establecer una sesin.
2. B solicita una clave de sesin al KDC.
3. El KDC enva a B la clave de sesin que utilizar para comunicarse con A y un
paquete cifrado para que B lo entregue a A, dicho paquete est cifrado con la
clave que slo conocen A y el KDC y contiene la clave de sesin con la que A se
comunicar con B as como un identificador de B.
4. B enva a A el paquete que le envo el KDC para A.
El modelo mixto es la combinacin del modelo PULL y el PUSH.
1. A se comunica con B y le hace saber que requiere establecer una sesin.
2. A y B solicitan una clave de sesin al KDC.
3. El KDC enva a A y B la clave de sesin que utilizarn para comunicarse.

Centro de distribucin de claves (KDC Key Distribution Center): verifica qu

equipos tienen permiso de comunicarse con otros, cuando la conexin est
permitida el KDC se encarga de dar una clave de sesin para dicha conexin. El
KDC puede ser una entidad centralizada en la red o ser un servicio distribuido en
varios nodos.
Un centro de traduccin de claves (KTC Key Translation Center) est formado
por el KDC y las entidades que desean establecer una sesin. La figura 3.3.7
muestra el esquema de un KTC.

Figura 3.3.7 KTC

Distribucin basada en certificado
Podemos diferenciar dos tcnicas para la distribucin basada en certificado:
1. Transferencia de claves: El emisor genera localmente una clave y la cifra con un
algoritmo asimtrico utilizando la llave pblica del receptor, con el objetivo de que
solo

ste

pueda

recuperarla

y as

protegerla

durante

su

transmisin.

La figura 3.3.8 muestra el esquema de esta tcnica.

Figura 3.3.8 Transferencia de claves

2. Intercambio de claves o acuerdo de claves: la clave es generada por las dos
entidades

involucradas

en

la

comunicacin.

Dentro del esquema de distribucin de claves basada en certificado, una autoridad

de certificacin (CA) debe autenticar las claves pblicas de las entidades que
desean intercambiar claves secretas, las claves pblicas son parte de la

informacin que proporciona un certificado. Por ejemplo identifiquemos a las dos

entidades que intercambiarn claves como A y B y a la CA la llamaremos D, si A y
B tienen certificados de la misma CA (en este caso D), A puede estar seguro de
que una determinada clave pblica pertenece a B, obteniendo el certificado de B y
comprobndolo con la clave pblica de D.

3.2. CERTIFICACIN.
Cuando un/a usuario/a accede a travs de certificado digital, tiene acceso a
servicios ms especficos y propios de su persona especfica.
Estos servicios son: consulta y correccin de datos personales y asistenciales,
eleccin de mdico y centro de salud, eleccin de durante un traslado temporal y
superior a un mes a otro municipio, solicitar una segunda Opinin Mdica,
consultar y anular una cita para registrar las Voluntades Vitales Anticipadas,
consultar el estado de la lista de espera para intervencin quirrgica.
El certificado digital tiene mltiples usos entre ellos el de identificar al usuario/a a
la hora de realizar gestiones con el Centro de Salud.
El DNI electrnico es emitido por la Polica Nacional, mientras que el certificado
digital de clase 2CA es emitido por la Fbrica Nacional de Moneda y Timbre.
Para acceder mediante certificado digital es necesario contar con el software
apropiado.

Fuente: InterS@S
Para acceder mediante este procedimiento se debe:

Acceder a InterS@S.

Hacer clic en el botn Mediante certificado digital.

Verificar si tenemos instalados todo lo necesario en nuestro ordenador.

Para ello deberemos hacer clic en Verificar componentes.

Leer y aceptar el mensaje que aparece en pantalla.

Seleccionar, descargar e instalar los componentes de la lista que

correspondan con nuestro sistema operativo.

Hacer clic en Ya he verificado los componentes.

Pulsar Conectar.

Seleccionar el certificado digital que queremos utilizar (aparecer un listado

con los certificados instalados en nuestro ordenador).

3.3. COMPONENTES DE UNA PKI

Es la combinacin de programas, tecnologas de encripcin, procesos, y servicios
que permite a las organizaciones asegurar las comunicaciones y las transacciones
del Negocio.

D. Componentes de una PKI

Una PKI (Public Key Infrastructure, infraestructura de clave pblica) es un

conjunto de elementos de infraestructura necesarios para la gestin de forma

segura de todos los componentes de una o varios Autoridades de Certificacin.
Por tanto, una PKI incluye los elementos de red, servidores, aplicaciones, etc.
Ahora vamos a identificar algunos de los componentes lgicos bsicos de una
infraestructura de clave pblica.

- Autoridad de certificacin CA. Una autoridad de certificacin es el

componente responsable de establecer las identidades y de crear los certificados

que forman una asociacin entre la identidad y una pareja de claves pblica y
privada.

- Autoridad de registro RA. Una autoridad de registro es la responsable del

registro y la autenticacin inicial de los usuarios a quienes se les expedir un

certificado posteriormente si cumplen todos los requisitos.

- Servidor de certificados. Es el componente encargado de expedir los

certificados aprobados por la autoridad de registro. La clave pblica generada para

el usuario se combina con otros datos de identificacin y todo ello se firma
digitalmente con la clave privada de la autoridad de certificacin.

- Repositorio de certificados. Es el componente encargado de hacer

disponibles las claves pblicas de las identidades registradas antes de que

puedan utilizar sus certificados. Suelen ser repositorios X.500 o LDAP. Cuando el
usuario necesita validar un certificado debe consultar el repositorio de certificados
para verificar la firma del firmante del certificado.

3.4. ARQUITECTURAS PKI.

La Arquitectura PKI se encuentra reflejada en el Internet Certificate and CRL
Profile RFC 3280, especificada por el Internet Engineering Task Force, y cuyo
sitio web se encuentra en la URL www.ietf.org.
La Infraestructura de Llave Pblica o PKI:
Es la integracin de:
a) La Criptografa de llave pblica o asimtrica, usada para la firma digital,
b) La Criptografa de llave simtrica usada para cifrar,
c) El Message Digest o Hash, y
d) La Gestin de los pares de Llaves Pblico / Privados (El no compromiso de la
llave privada, a travs de un procedimiento de distribucin segura de llaves.)
La Criptografa de Llave Pblica o Asimtrica: Tiene por objeto distribuir la llave
simtrica de forma segura. Est basada en el uso de un par de llaves, una pblica
y otra privada, por cada entidad. La Llave Privada debe permanecer en secreto y
bajo el control del usuario. Usarla para cifrar descifrar es lo que demuestra que
la posees y con ello queda garantizada la autenticidad y confidencialidad, La
identidad. La Llave Pblica puede y debe ser libremente distribuida, lo ms
extensamente. Dichas llaves se caracterizan por qu:

son diferentes,

estn matemticamente asociadas,

no se puede obtener la llave privada a partir de la pblica. Cada llave

nicamente puede descifrar lo que la otra ha cifrado, por tanto; a.-con la llave
pblica del suscriptor, cualquiera puede cifrar un mensaje, que solo puede ser
descifrado por la llave privada del suscriptor, se logra la confidencialidad.
Con la llave pblica del suscriptor, cualquiera puede descifrar un mensaje, y as
verificar la identidad del documento que ha sido cifrado por el suscriptor usando su
llave privada.
Sus implicaciones son las siguientes:
a.-El suscriptor puede establecer la integridad y el origen (autora) de la
informacin (datos) que enva a otro participante, firmando digitalmente dicha
informacin, cifrndola con su llave privada.
b.-Quien recibe la informacin puede usar la llave pblica asociada del suscriptor
para validar que proviene del suscriptor (tenedor de la llave privada), y verificar la
integridad de la informacin.
Criptografa de Llave Simtrica o Secreta:
Se basa en el uso de una nica llave entre las partes implicadas, suscriptor y
verificador.
El proceso de cifrado con llave simtrica usa un algoritmo, la llave, el mensaje y el
message digest, siendo muy complicado por mtodos informticos obtener el
camino inverso.
Algoritmos: DSA Digital Signing Algorithm, de tipo irreversible, soportado por Java,
o RSA Rivest Shamir Adleman, de tipo reversible, que est ya preparada para
usar la firma digital, y el cifrado.
El Message Digest Value:
El Message Digest, o Hash, es una versin corta y de longitud fija de un
mensaje, que no se puede recobrar a partir del Message Digest. Es
completamente diferente si cambia un solo bit del mensaje original.

El suscriptor lo obtiene a partir de; algoritmos de message digest como SHA-1,

Ripe_MD, o algoritmos de firma digital que lo incluyen como DSA o RSA, Ms el
mensaje original, y la llave privada del suscriptor.
Y el verificador lo obtiene descifrando la firma digital recibida del suscriptor,
utilizando la llave pblica del suscriptor, y el algoritmo de firma digital.
Da por resultado un valor, o Message Digest Value.
El objeto es que el verificador se asegure de la integridad de los datos
transmitidos, lo que se logra comparando el valor del message digest descifrado
por el verificador utilizando su llave privada, y el que ha recibido, descifrado por la
llave pblica del suscriptor. Si stos son iguales, entonces se confirma la
integridad del mensaje.
El Modelo PKIX:
El Modelo PKIX es el modelo de las entidades que gestionan la infraestructura de
llave pblica, designando sus funciones y protocolos.
1 Entidades Finales (a quien se pretende identificar)

El sujeto de un certificado, su identidad es garantizada por una autoridad de

certificacin.

stas pueden ser Usuarios finales, la autoridad de registro respecto a la

autoridad de certificacin en el nombre de quien acta, o incluso una autoridad de

certificacin cuando sta se ve certificada por otra autoridad de certificacin.
2 Autoridades de Certificacin (CA)

Representan la fuente de credibilidad de la infraestructura de llave pblica.

Quienes emiten los certificados, firmndolos digitalmente con su llave

privada.

Certifican que la llave pblica asignada en un certificado a una entidad final,

corresponde

realmente

www.pkiforum.org.

dicha

entidad

final.

Ver:

CA

Trust.pdf

en

Verisign es el representante ms conocido.

3 Autoridad de Registro, o Registration Authority (RA)

Realiza el proceso de registro de las entidades finales por encargo de la

autoridad de certificacin.

Valida los atributos del sujeto que solicita el certificado,

Verifica que el sujeto posee la llave privada a registrar,

Genera los secretos compartidos que permiten el proceso de inicializacin y

certificacin.

Genera el par de llaves pblico/privada, ver ANSI X.9 standards.

Valida los parmetros de las llaves pblicas presentadas para su registro.

4 Repositorios o Repositories
Mtodo que permite guardar informacin sobre PKI, como puedan ser certificados,
y CRLs para su acceso por parte de las entidades finales o de sus delegados.
Tienen por finalidad que la entidad final obtenga la confirmacin sobre:

el estatus de revocacin de los certificados de otros usuarios, y

la validacin del Certification Path, o cadena de certificados.

5 Emisores de CRLs o Certificate Revocation List Issuers

Los emisores de Listas de Revocacin de Certificados actan en nombre de la
Autoridad de Certificacin, siendo de carcter opcional aunque sumamente
convenientes. Son listas de los Certificados que han dejado de ser vlidos y por
tanto en los que no se puede confiar. Los Certificados son revocados en los casos
en los cuales:
a) la llave privada se vea comprometida,
b) hayan cambiado los atributos del certificado.
Procedimiento de la Certificacin:

1 Solicitud a la Autoridad de Certificacin de un certificado por parte de la Entidad

Final, a travs de la Autoridad de Registro, con el objeto de que la Autoridad de
Certificacin garantice la identidad de la entidad final.
2 La Autoridad de Certificacin comprueba que cada usuario es quien dice ser y
que la clave pblica que inscriba en el certificado realmente le pertenece.
3 El Certificado de la entidad final se firma digitalmente, cifrndolo con la llave
privada de la Autoridad de Certificacin.
4 A su vez la autoridad de certificacin es certificada por otra/s Autoridad/es de
Certificacin.
5 Dicho certificado se distribuye globalmente, es decir, al mayor numero de
destinatarios posibles.
Los Certificados Digitales
Son documentos que confirman la identidad de una persona fsica o jurdica,
vinculada con una llave pblica asociada a la llave privada. Tienen dos aspectos
por objeto:
1- Que la llave pblica del suscriptor pueda ser accesible por los verificadores o
participes interesados en validar y verificar la firma digital del suscriptor.
2-Que los partcipes puedan confiar en que la llave pblica que recibe el
verificador sea realmente la del suscriptor.
Contenido del Certificado
Estos son los campos principales incluidos como contenido

Identificador nico o N de serie del certificado. Internacional, y desarrollado

El algoritmo de firma digital empleado. por Internet Engineering Task

Datos de la autoridad de Certificacin: ID nico del Force.

emisor de certificados.

Fechas de expedicin y expiracin de la llave pblica y privada.

Llave pblica del titular del certificado.

Usos del Certificado

1. Personales:
a) Nombre y apellidos, o pseudnimo. El certificado Digital
b) N de telfono(s).
c) Direccin fsica y e-mail.
d) CI (cdula de identificacin)
e) Profesin y titulacin.
f) Cargo y empresa.
g) Grupo(s) de afiliacin.
2. Profesionales:
a) Para personas jurdicas todo lo anterior y adems: b) Nombre de la persona
jurdica. c) Poder notarial del poseedor del certificado.
Concepto de Cadena de Certificacin
Una Autoridad de Certificacin puede a su vez estar certificada por otra/s,
Autoridades de Certificacin, con su firma digital, hasta llegar a la Autoridad de
Certificacin Raz, lo que conforma la Cadena de Certificados o Certification
Path de cualquier certificado hasta su Anclaje de Veracidad o Trust Anchor,
que termina en el Certificado Raz de la Autoridad de Certificacin Raz. Dicho
certificado Raz es un certificado firmado a s mismo, y emitido por la Autoridad de
Certificacin Raz.
Las Entidades Finales por tanto deben validar la Cadena de Certificados para
comprobar que los Certificados Digitales realmente certifican que la llave pblica
es de quien dice ser, comenzando para validarlo por los Trust Anchors.

Tipos de Certificado Digital

Certificados de Clase 1:
Son emitidos nicamente a individuos. No se verifica la identidad de stos y por
tanto no permite autentificarla. Confirman que el nombre o seudnimo y el sujeto
del certificado forman un nombre de sujeto inequvoco.
Certificados de Clase 2:
Son emitidos nicamente a individuos, y confirman que la informacin
proporcionada por el Suscriptor no entra en conflicto con la informacin de las
bases de datos fiables propiedad de una EE (Entidad de Emisin) o una ERL
(Entidad de Registro Local), incluida la identidad del sujeto y otros datos del
Suscriptor.
a) Certificados de Clase 2 no reconocidos (Clase 2 tipo 1), usados para
transacciones de bajo riesgo como servicios de suscripcin de la Sociedad de la
Informacin.
b) Certificados de Clase 2 reconocidos (Clase 2 tipo 2), pueden ser usados como
soporte de firmas electrnicas legalmente reconocidas, obtienen una razonable
seguridad de la identidad del Suscriptor, comparando automticamente el nombre
del solicitante, direccin y otra informacin personal contenida en la solicitud de
certificado, con la informacin contenida en las bases de datos propiedad de la EE
o ERL.
Certificados de Clase 3, se emiten a:

Individuos: requiere la presentacin de evidencias probatorias de la

identidad de la identidad del sujeto, personndose ante una Entidad de Registro

Local (ERL) o su delegado, como puede ser un notario pblico.

Organizaciones: se emiten a individuos con capacidad de firma dentro de

una organizacin, probada esta capacidad de firma por evidencia notarial, y de la

propia organizacin a travs de ministros de fe que confirmen su identidad.

Las polticas y prcticas de certificacin, CPS y CP:

Declaracin de Prcticas de Certificacin (CPS)

Describe las prcticas empleadas en la emisin y gestin de certificados.

Gobierna la gestin de la Infraestructura de llaves pblicas, y podra tambin

incluir la descripcin de los servicios ofrecidos, y el detalle de los procedimientos
de la gestin del ciclo de vida del certificado, informacin operacional, etc.

La Declaracin de Practicas de Certificacin provee de un marco legal que

describe las obligaciones y mrgenes de responsabilidad que asume la Autoridad

de Certificacin, as como sus derechos con los titulares de los certificados
emitidos por sta.
Poltica de Certificacin (CP)

Consiste en un conjunto de reglas que indican la aplicabilidad de un

certificado

una

particular

comunidad

y/o

clase

de

aplicaciones

requerimientos de seguridad comunes.

Generalmente se fija en los requerimientos de polticas de alto nivel.

con

3.5. POLTICAS Y PRCTICAS DE CERTIFICACIN.

"Poltica de Certificacin" (en ingls CP o Certificate Policy), que recoge las
caractersticas particulares del certificado. Existe una poltica de certificacin por
cada tipo de certificado emitido.
Firma profesional pone a disposicin de sus clientes sus Condiciones Generales
de Contratacin, por las que se rigen las adquisiciones de cualquiera de nuestros
certificados. A estas, hay que sumarles las Condiciones Particulares de
Contratacin que aparecen reflejadas en el contrato firmado entre el cliente y
Firma profesional. Consulte nuestras Condiciones Generales de Contratacin.
Firma profesional cumple con las ms estrictas medidas de seguridad, siguiendo
las directrices marcadas por Web Trust y ISO 27001. Como prueba del
compromiso de la Direccin de Firma profesional con la seguridad se muestra la
siguiente declaracin pblica.
Una poltica de seguridad en el mbito de la criptografa de clave pblica o PKI es
un plan de accin para afrontar riesgos de seguridad, o un conjunto de reglas para
el mantenimiento de cierto nivel de seguridad. Pueden cubrir cualquier cosa desde
buenas prcticas para la seguridad de un solo ordenador, reglas de una empresa
o edificio, hasta las directrices de seguridad de un pas entero.
La poltica de seguridad es un documento de alto nivel que denota el compromiso
de la gerencia con la seguridad de la informacin. Contiene la definicin de la
seguridad de la informacin bajo el punto de vista de cierta entidad.
Debe ser enriquecida y compatibilizada con otras polticas dependientes de sta,
objetivos de seguridad, procedimientos (vase referencias ms adelante). Debe
estar fcilmente accesible de forma que los empleados estn al tanto de su
existencia y entiendan su contenido. Puede ser tambin un documento nico o
inserto en un manual de seguridad. Se debe designar un propietario que ser el

responsable de su mantenimiento y su actualizacin a cualquier cambio que se

requiera.

3.6. GESTIN DE UNA PKI.

Esta tendencia conduce a sistemas de informacin conectados e integrados a
travs de la infraestructura que proporciona Internet, e introduce un nuevo entorno
donde la funcionalidad de las aplicaciones se ofrece y accede como servicio. Al
realizar cada servicio una tarea bien definida, se tiene una baja dependencia entre
componentes de software que interactan entre s, lo cual permite dotar de
flexibilidad la infraestructura tecnolgica de un negocio, para que pueda responder
a los cambios organizacionales u operacionales que traiga consigo la constante
transformacin del entorno en el que se desenvuelve.
Cualquier tecnologa basada en servicios se puede utilizar para implementar SOA.
Al ser esta una filosofa o enfoque de arquitectura, donde todas las actividades o
procesos estn diseados para ofrecer un servicio, no especifica un protocolo
especfico a travs del cual deban ofrecerse dichos servicios. CORBA (Common
Object Request Broker Architecture), DCOM (Distributed Complement Object
Model), RMI (Remote Method Invocation), ICE (Internet Communications Engine),
EJB (Enterprise JavaBeans), MQSeries (hoy WebSphere) de IBM, ESB
(Enterprise Service Bus), JMS (Java Messaging Service) y Web Services son
algunas de las propuestas existentes para implementar SOA.
De todos estos, Web Services se postula como la tecnologa ms comn para
posibilitar arquitecturas orientadas a servicios, ya que se apoya en estndares,
permite la integracin de los procesos de negocio y proporciona interoperabilidad
al ser independiente de plataformas, protocolos y lenguajes de implementacin.
Por otro lado, la necesidad de ofrecer un entorno confiable para el intercambio de
informacin en red, hace que PKI se convierta en una alternativa a evaluar por las

organizaciones para cumplir con este propsito Comercio electrnico seguro,

comunicaciones confidenciales y transacciones fiables son posibles con PKI, des
afortunadamente las organizaciones enfrentan muchos problemas a la hora de
adoptar este tipo de solucin pues es una tecnologa costosa, tiene problemas de
interoperabilidad y escalabilidad y resulta complicada para los usuarios finales.
Por lo tanto, a pesar de que en teora son varias las utilidades y beneficios que
traen consigo SOA y PKI, la implementacin de esto en una organizacin es una
tarea laboriosa: implica esfuerzo econmico, operativo, administrativo y cambios
en la cultura organizacional.
La realidad de las organizaciones es que, aunque quieran estar actualizadas y
sacar provecho de los avances que da a da ofrece la industria tecnolgica, optan
por soluciones menos costosas, menos confusas y ms rpidas y simples de
implantar.

3.7 ESTNDARES Y PROTOCOLOS DE CERTIFICACIN.

El Protocolo SET (Secure Electronic Transaction o Transaccin Electrnica
Segura) es un sistema de comunicaciones que permite gestionar de una forma
segura las transacciones comerciales en la Red. Y cuando decimos de una forma
segura nos referimos a que aporta un mayor nivel de seguridad que su antecesor
el SSL. Precisamente esa fue la razn que dio origen a su nacimiento.
Estndares tecnolgicos

Los estndares tecnolgicos son aqullos que proporcionan un entorno de trabajo

para el desarrollo de software y de aplicaciones que permiten el acceso y
procesamiento de datos geogrficos procedentes de diversas fuentes, a travs de
interfaces genricas dentro de un entorno tecnolgico abierto basado en
estndares y protocolos amplia mente conocidos por la comunidad mundial de
informacin geogrfica y por la comunidad web.

Como tal, los estndares tecnolgicos describen las tareas y la manera como se
emplea la tecnologa y la informacin para cumplir con metas de las diferentes
entidades relacionadas con acceso y publicacin de informacin geogrfica en
lnea. Estos estndares tambin pueden llamarse estndares de servicios, los
cuales describen los procedimientos y las metodologas para disponer la
informacin geogrfica en la web permitiendo diferentes niveles de publicacin,
tales como visualizacin, uso, descarga, procesamiento, acceso, etc.

Este tipo de estndares est relacionado con las especificaciones de la OGC. La

especificacin de implementacin de OGC est detallada en el marco de trabajo

del desarrollo de software para el acceso distribuido a los datos geogrficos y a los
recursos de procesamiento en lnea de datos geogrficos. Esta especificacin
proporciona tanto a los desarrolladores de software como a los usuarios de
informacin geogrfica, unas interfaces comunes detalladas que permiten que
herramientas de software desarrolladas por comunidades privadas y/o bajo
filosofa de cdigo abierto, puedan interoperar entre s con informacin geogrfica
permitiendo el intercambio, uso y acceso de manera masiva a esta clase de datos.
Ejemplo de protocolo y estndares:

Protocolo de Emisin de un Sello de Tiempo

El usuario se identifica ante el sistema mediante certificado electrnico.

El servidor TSU establece comunicacin con el servicio OCSP Responder y
determina el estado de vigencia del certificado.
El TSU determina el estado de consumo de la cuenta cliente del usuario (servicio
de pago).
El usuario enva el valor hash de un documento D; es decir, h(D), al servidor TSU.
El TSU aade al valor recibido el tiempo t, en la forma de fecha y hora de la
recepcin, componiendo (h(D), t).
El TSU procede a la firma digital de la asociacin anterior, incluyendo los atributos,
y se construye el Sello de Tiempo. El proceso de firma se realiza con un
certificado que identifica al TSU emisor.
El TSU enva este Sello Digital de Tiempo al usuario. De esta forma, el usuario
puede verificar el sello y probar ante otros que D exista en el tiempo t, con tan
slo verificar en cualquier momento la firma de la Autoridad de Timestamping.
El Sello de Tiempo, al incorporar el certificado del servidor TSU, permite
determinar el TSU que lo emiti. El tiempo medio que un servidor TSU de ANF AC
tarda en procesar un Sello de Tiempo es de 0,219 segundos.

Normas y Estndares

Todos los componentes que intervienen en el Servicio de Timestamping han sido

desarrollados por el Departamento de Ingeniera de ANF AC, siguiendo y
respectando las normas tcnicas internacionales.

Entre ellas destaca el documento RFC 5816 "Internet X.509 Public Key
Infrastructure Time-Stamp Protocol" de la IETF (Internet Task Engineering Force),
que actualiza el RFC 3161 de agosto de 2001 y es conforme con la norma ETSI
TS 101 861.

Este documento determina que el Sellado Digital de Tiempo confiable se emite por
un tercero de confianza, que acta como Autoridad de Sellado de Tiempo o TSA
(Time Stamping Authority). Asimismo permite el uso de la estructura ESSCertIDv2,
tal como se define en el RFC 5035, para especificar el valor hash de un certificado
del firmante, cuando el hash se calcula con una funcin distinta al algoritmo SHA1.

Normas de referencia respetadas por ANT TSA AC

[RFC 5816] "Internet X.509 Public Key Infrastructure Time-Stamp Protocol

(TSP)" (actualiza RFC 3161)

RFC 3628 Policy Requirements for Time Stamping Authorities (TSAs)

[TS 101 861] ETSI Technical Specification TS 101 861 V1.2.1. (2001-11).
Time stamping profile

[TS 102 023] ETSI Technical Specification TS 102 023. Policy requirements
for Time stamping Authorities

[ISO 18014] Time-stamping services is an international standard that

specifies Time stamping techniques

[ISO 8601] Data elements and interchange formats Information

interchange Representation of dates and times

[TF.460-5] ITU-R Recommendation TF.460-5 (1997): Standard- frequency

and time-signal emissions

[TF.536-1] ITU-R Recommendation TF.536-1 (1998): Time-scale nota

3.8. EJEMPLO DE UN PROTOCOLO DE SEGURIDAD:

HTTPS.
El protocolo HTTP es permitir la transferencia de archivos (principalmente, en
formato HTML). entre un navegador (el cliente) y un servidor web (denominado,
entre otros, HTTP en equipos UNIX) localizado mediante una cadena de
caracteres denominada direccin URL.
Comunicacin entre el navegador y el servidor
La comunicacin entre el navegador y el servidor se lleva a cabo en dos etapas:

El navegador realiza una solicitud HTTP

El servidor procesa la solicitud y despus enva una respuesta HTTP
En realidad, la comunicacin se realiza en ms etapas si se considera el
procesamiento de la solicitud en el servidor. Dado que slo nos ocupamos del
protocolo HTTP, no se explicar la parte del procesamiento en el servidor en esta
seccin del artculo. Si este tema les interesa, puede consultar el articulo sobre el
tratamiento de CGI.
Una solicitud HTTP es un conjunto de lneas que el navegador enva al servidor.
Incluye:

Una lnea de solicitud: es una lnea que especifica el tipo de documento

solicitado, el mtodo que se aplicar y la versin del protocolo utilizada. La
lnea est formada por tres elementos que deben estar separados por un
espacio:

el mtodo

la direccin URL
la versin del protocolo utilizada por el cliente (por lo general,HTTP/1.0)
Los campos del encabezado de solicitud: es un conjunto de lneas
opcionales que permiten aportar informacin adicional sobre la solicitud y/o el
cliente (navegador, sistema operativo, etc.). Cada una de estas lneas est
formada por un nombre que describe el tipo de encabezado, seguido de dos
puntos (:) y el valor del encabezado.
El cuerpo de la solicitud: es un conjunto de lneas opcionales que deben estar
separadas de las lneas precedentes por una lnea en blanco y, por ejemplo,
permiten que se enven datos por un comando POST durante la transmisin de
datos al servidor utilizando un formulario.
Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno
de carro y avance de lnea):
MTODO VERSIN URL<crlf>
ENCABEZADO: Valor<crlf>
. . . ENCABEZADO: Valor<crlf>
Lnea en blanco <crlf>
CUERPO DE LA SOLICITUD
A continuacin se encuentra un ejemplo de una solicitud HTTP:
GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since :
Saturday, 15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible;
MSIE 5.0; Windows 95)
Comandos
Comando Descripcin
GET

Solicita el recurso ubicado en la URL especificada

HEAD

Solicita el encabezado del recurso ubicado en la URL

especificada

POST

Enva datos al programa ubicado en la URL especificada

PUT

Enva datos a la URL especificada

DELETE

Borra el recurso ubicado en la URL especificada

Encabezados
Nombre del
encabezado

Descripcin

Accept

Tipo de contenido aceptado por el navegador (por

ejemplo, texto/html). Consulte Tipos de MIME

Accept-Charset

Juego de caracteres que el navegador espera

Accept-Encoding

Codificacin de datos que el navegador acepta

Accept-Language Idioma que el navegador espera (de forma

predeterminada, ingls)
Authorization

Identificacin del navegador en el servidor

Content-Encoding Tipo de codificacin para el cuerpo de la solicitud

ContentLanguage

Tipo de idioma en el cuerpo de la solicitud

Content-Length

Extensin del cuerpo de la solicitud

Content-Type

Tipo de contenido del cuerpo de la solicitud (por

ejemplo, texto/html). Consulte Tipos de MIME

Date

Fecha en que comienza la transferencia de datos

Forwarded

Utilizado por equipos intermediarios entre el navegador

y el servidor

From

Permite especificar la direccin de correo electrnico del

cliente

From

Permite especificar que debe enviarse el documento si

ha sido modificado desde una fecha en particular

Link

Vnculo entre dos direcciones URL

Orig-URL

Direccin URL donde se origin la solicitud

Referer

Direccin URL desde la cual se realiz la solicitud

User-Agent

Cadena con informacin sobre el cliente, por ejemplo, el

nombre y la versin del navegador y el sistema
operativo

Respuesta HTTP
Una respuesta HTTP es un conjunto de lneas que el servidor enva al navegador.
Est constituida por: Incluye:

Una lnea de estado: es una lnea que especifica la versin del protocolo
utilizada y el estado de la solicitud en proceso mediante un texto explicativo y
un cdigo. La lnea est compuesta por tres elementos que deben estar
separados por un espacio: La lnea est formada por tres elementos que deben
estar separados por un espacio:

la versin del protocolo utilizada

el cdigo de estado

el significado del cdigo

Los campos del encabezado de respuesta: es un conjunto de lneas
opcionales que permiten aportar informacin adicional sobre la respuesta y/o el
servidor. Cada una de estas lneas est compuesta por un nombre que califica
el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado
Cada una de estas lneas est formada por un nombre que describe el tipo de
encabezado, seguido de dos puntos (:) y el valor del encabezado.

3.9. SSL, TSL, SSH.

PGP fue diseado hace ya casi diez aos, por lo que fue pensando en archivos,
no en conexiones de red. Un archivo tiene un contenido fijo que queremos
transmitir, en tanto que una sesin de red debe ir transmitiendo dinmicamente
conforme vaya siendo necesario. Adems, tomando en cuenta que un servidor
recibir grandes cantidades de conexiones de red simultneas, no podemos
darnos el lujo de cifrar y descifrar toda la comunicacin utilizando algoritmos de
llave pblica, dado el alto costo computacional que esto conllevara. Sin embargo,
tampoco podemos darnos el lujo de confiar en algoritmos de llave simtrica - Dado
un nmero tan grande de posibles conexiones, cuntas llaves secretas
deberamos guardar para poder comunicarnos con cada host de Inernet? Cmo
podramos confiar en que un atacante externo no ha conseguido acceso a alguna
de estas llaves, espiando o modificando as nuestros datos?
Estas tres familias de protocolos (SSH: Secure Shell. SSL: Secure Socket Layer.
TLS: Transport Layer Security) funcionan con el mismo principio bsico: El primer
intercambio de informacin entre cliente y servidor es el envo de las llaves
pblicas de ambos. De esta manera, se puede entablar una sesin con
comunicacin segura. Acto seguido, una de las partes (o entre ambas) crean
aleatoriamente una llave secreta, que ser utilizada nicamente durante la sesin
en cuestin, y ser descartada inmediatamente al terminar sta. De ah en
adelante, la sesin se maneja cifrndola nicamente con un algoritmo de llave
simtrica.
SSH es principalmente utilizado para el acceso remoto a computadoras Unix,
aunque tambin es utilizado para realizar transferencias de archivos.

SSL es una envoltura que se puede aplicar a prcticamente cualquier protocolo

TCP, encargndose de mantener una comunicacin segura entre dos hosts sin
importarle qu tipo de datos est enviando. Las versiones seguras de http, pop3,
imap, smtp y otros varios servicios viajan sobre tneles SSL.
TLS busca integrar un esquema tipo SSL al sistema operativo - SSL hace
nicamente tneles, redireccionando la entrada y salida procesadas de un puerto
seguro a un puerto inseguro. TLS busca hacer esto a nivel de la capa TCP/IP,
para que este tnele o sea realmente transparente a las aplicaciones.

SSH: se usa, principalmente, para proporcionar acceso remoto a computadoras

Unix,

aunque

tambin

se

usa

para

transferencias

de

archivos.

SSL: hace tneles, redirecciona la informacin de un puerto inseguro a uno

seguro. Su puede aplicar a muchos protocolos TCP proporcionando una
comunicacin segura entre dos hosts y dando lugar a las versiones seguras de
dichos protocolos. Https o pop3s, por ejemplo, son versiones seguras de
protocolos

que

viajan

en

tneles

SSL.

TLS: busca integrar un esquema tipo SSL al sistema operativo. Proporciona el

mecanismo para que los tneles de los protocolos seguros funcione a nivel de la
capa TCP/IP y resulte transparente para las aplicaciones.

3.10. PRUEBA CON UN GENERADOR DE CERTIFICADOS

GRATUITO, LIBRE Y EN LNEA.
El OpenCA PKI Research Labs, nacida de la antigua Proyecto OpenCA, es una

organizacin abierta dirigida a proporcionar un marco para el estudio de PKI y

desarrollo de proyectos relacionados. A medida que el PKI normas, intereses y
proyectos estn creciendo rpidamente, se ha decidido dividir el proyecto original
en otros ms pequeos para acelerar y reorganizar los esfuerzos. Algunos
proyectos ya han comenzado y recibidos (siempre que sea posible) los fondos,
mientras que otros estn encontrando su camino a la etapa de decisin final.

OCSPD v2.4.3 ( BEHAPPY )

La nueva versin ( v2.4.3/BeHappy ) de OCSPD del OpenCA disponible. Cambios

en su mayora implican la actualizacin de soporte para LibPKI 0.8.1 que corrige
un problema de anlisis de URI con peticiones HTTP GET . Descarga la nueva
versin de su sistema en las pginas de descarga OCSPD .

LIBPKI v0.8.1 ( Bemore )

La nueva versin ( v0.8.1/BeMore ) de LibPKI disponible. Cambios en su mayora

implican la correccin de errores y anlisis de URI ( corrige un error en OpenCA
OCSPD con peticiones HTTP GET ) . Descarga la nueva versin de su sistema en
las pginas de descarga LibPKI .

OCSPD v2.4.2 ( Ocampa )

Una nueva versin de la OCSPD respondedor est disponible para su descarga.

Las principales mejoras respecto a la ltima versin disponible al pblico son:
soporte actualizado para LibPKI 0.8.0 +, inicio fija / parada guin, prdidas de
memoria fija , Corregido el error en la configuracin que impide la recarga de las
CRL caducadas , mejora el tiempo de respuesta , soporte fijo para la solicitud GET
tipos .

OpenCA PKI V1.5.0 ( SpecialK )

El OpenCA PKI v.1.5.1 ( SpecialK ) est fuera ! Esta versin incorpora todas las
correcciones de errores de la v1.3.0 . Los cambios estn disponibles en el enlace
Registro de cambios desde la pgina de descargas OpenCA .

LIBPKI v0.8.0 ( secuestrar )

La nueva versin ( v0.8.0/Sequester ) de LibPKI disponible. Cambios en su

mayora implican la correccin de errores . Descarga la nueva versin de su
sistema en las pginas de descarga LibPKI .

LIBPKI V0.6.7 ( PAPOCCHIO )

La nueva versin ( v0.6.7/Papocchio ) de LibPKI disponible. Los principales

cambios son ms v0.6.5 : inicializacin respuesta OCSP fija, aade soporte para
url DNS para recuperar los registros DNS a travs de la simple URL_ * interfaz,
aadido soporte inicial para el peso ligero Tokens revocacin de Internet ( LIRTs )
descargar la nueva versin de su sistema en el LibPKI descargar pginas .

LIBPKI V0.6.5 (HOPE )

La nueva versin ( v0.6.5/Hope ) de LibPKI disponible. Los principales cambios

son ms v0.6.4 : Corregido un error de codificacin de clave en OpenSSL , aadi
nueva pki - siginfo herramienta para facilitar la informacin recogida de firmas para
X509 objs , aadi PKI_X509_KEYPAIR_get_curve () para obtener la curva en
relacin con una clave de EC , aadi posibilidad de cargar cualquier tipo de X509
objetos mediante PKI_X509_get () con PKI_DATATYPE_ANY como un tipo , fija
un error al configurar el algoritmo de firma en PKI_X509_CERT_new (), soporte
mejorado para la gestin de claves ECDSA . Descarga la nueva versin de su
sistema en las pginas de descarga LibPKI .

LIBPKI V0.6.4 ( BROADWAY )

La nueva versin ( v0.6.4/Broadway ) de LibPKI disponible. Los principales

cambios son ms v0.6.3 : cdigo HTTP fijo ( error de asignacin de memoria) , el
aumento de la herramienta de lnea de comandos para la manipulacin de CRL (
pki -CRL ) . Descarga la nueva versin de su sistema en las pginas de descarga
LibPKI .

OCSPD V2.1.0 ( ELLIE )

Una nueva versin de la OCSPD respondedor est disponible para su descarga.

Las principales mejoras respecto a la ltima versin disponible al pblico son:
Actualizado archivos predeterminados de configuracin ( Passin defecto es
ninguno) , soporte mejorado para el apoyo ECDSA , gestin de hilo actualizado
con soporte incorporado de LibPKI 0.6.3 , script de arranque / parada fija , fija un
error de memoria en config.c causando segfault de recarga CRL , eliminan extra
de dos bytes enviados despus de la codificacin DER de la respuesta se escribe
( que estaba causando Firefox / Thunderbird no para validar la respuesta ) , fija un
error en la devolucin de cheques cdigo para PKI_NET_listen , fijado error en el
anlisis de configuracin cuando se dio ninguna direccin de enlace.

LIBPKI V0.6.3 ( VIPER )

La nueva versin ( Viper/v0.6.3 ) de LibPKI disponible. Los principales cambios

son ms v0.6.1 : soporte ampliado para ECDSA ( a travs del perfil / keyparams
en archivos de configuracin del perfil ) , vinculador fijos en Solaris , agreg pki cert herramienta de lnea de comandos, cdigo de la biblioteca ocsp fijo. Descarga
la nueva versin de su sistema en las pginas de descarga LibPKI .

DemoCA en directo por madwolf@12.12.2010

La demostracin en lnea CA est de vuelta en lnea, debido a la gran demanda de
personas interesadas en el software OpenCA PKI. Vamos a tratar de mantenerlo
en lnea tanto como sea posible , por favor ten cuidado, sin embargo, que es slo
un servicio de DEMO y ninguna responsabilidad est implcita .

Versin actual de la lnea CA es v1.1.1 .

OCSPD FIREFOX FIX

Debido a un bug en Firefox ( gestin de memoria ) , es necesario tener la OCSPD

ser compilado con la LibPKI v0.6.1 + . Por favor, descargue el cdigo fuente y
volver a compilar el demonio de una vez al da la biblioteca de criptografa .

OCSPD 2.0.0

Una nueva versin de la OCSPD respondedor est disponible para su descarga.

Las principales mejoras respecto a la ltima versin disponible al pblico ( en su
mayora procedentes de apoyo para LibPKI v0.6.0 ) son: un amplio soporte para
los dispositivos de hardware ( PKCS # 11 y OpenSSL Motor) , par de claves
mltiples y soporte certificado para firmas de respuesta , POST y GET apoyo ,
IPv6 apoyar .

LIBPKI v0.6.0 ( TURQUA )

La nueva versin ( Turkey/v0.6.0 ) de LibPKI disponible. Los cambios importantes

durante v0.5.1 son: soporte para IPv6 en las llamadas de red , soluciones para
anlisis de la URL y PKI_SSL_ * Mejoras en la interfaz . Obtener la nueva versin
de su sistema en las pginas de descarga LibPKI .

LIBPKI v0.5.1 ( ZOIBERG )

La nueva versin ( Zoiberg/v0.5.1 ) de LibPKI disponible. Los principales cambios

son ms v0.5.0 : . Mejor soporte para OS Gestin Thread independiente junto con
las primitivas de sincronizacin de subprocesos ( mutexes , variables de estado, y
las cerraduras r / w , correcciones de interfaz LDAP Obtener la nueva versin de
su sistema en las pginas de descarga LibPKI .

Repositorios yum
28.08.2010 # Madwolf

Repositorios Yum para proyectos OpenCA se han creado. Si su sistema es

compatible con Yum (y RPM), puede utilizar los enlaces proporcionados para
instalar la configuracin del repositorio en su sistema.

BIBLIOGRAFIA

http://redyseguridad.fip.unam.mx/proyectos/criptografia/criptografia/index.php/3-gestion-declaves/33-generadores-y-distribucion-de-claves/333-distribucion-de-claves

http://www.entidadacreditadora.gob.cl/?p=428

https://www.firmaprofesional.com/images/pdfs/CPS/RG10503Declaracion_Politica_Seguridad-WT4CA-2013.pdf

http://gwolf.org/files/pki/node9.html