¿Qué es un Certificado SSL?

Técnicamente, los ID Digitales, también conocidos como certificados digitales, ligan la

identidad de su organización a un par de llaves electrónicas que pueden ser usadas para
encriptar y firmar información digital. Un ID Digital hace posible verificar la
afirmación de alguien de tener el derecho de usar una llave dada, ayudando a evitar que
gente use llaves falsificadas para hacerse pasar por otros usuarios. Al usarlo junto con la
encriptación, los ID Digitales proporcionan una solución de seguridad completa,
asegurando la identidad de una o de todas las partes involucradas en una transacción.

Un ID Digital es emitido por una tercera parte de confianza denominada Autoridad de

Certificación (CA). Una CA actua en cierto modo como una oficina de pasaportes. Las
CAs deben seguir ciertos pasos para establecer la identidad de las personas u
organizaciones para las cuales emiten IDs. Una vez que la CA establece la identidad de
una organización, emite un certificado que contiene la llave pública de la organización y
la firma con la llave privada de la CA.

Al usar un Certificado SSL de 40-bits , está habilitando su sitio para conducir comercio
en línea autenticado y encriptado. Los usuarios que visitan su sitio podrán remitir
números de tarjetas de crédito u otra información personal a su sitio con la seguridad de
que ellos están haciendo negocios con usted (y no con un impostor) y que la
información que ellos le están enviando no puede ser interceptada o desencriptada por
alguien que no sea el receptor esperado.

Su Certificado SSL incluirá la siguiente información:

• Nombre común de su organización (p.e. www.verisign.com)

• Informacion de identificación adicional (p.e. IP y dirección física)
• Llave pública del propietario
• Fecha de expiración de la llave pública
• Nombre del emisor (la Autoridad de Certificación que emitió ID Digital)
• Número de Serie único

• Firma Digital de VeriSign

PGP: SEGURIDAD EN E-MAIL

El PGP (Pretty Good Privacy ó Encriptación bastante buena) es un sistema de encriptación por llave
pública escrito por Philip Zimmermann, y sirve para que nadie salvo uno mismo y el destinatario o
destinatarios a los que vaya dirigido el mensaje puedan leerlo al ir los mensajes codificados, también
puede usarse para comprobar la autenticidad del mensaje asegurándonos que lo ha escrito el remitente
en realidad, realmente es muy bueno y es prácticamente indescifrable, esto mismo le ha llevado al autor
del mismo Philip Zimmermann a tener bastantes quebraderos de cabeza con la ley en Estados Unidos,
afortunadamente su caso ya se ha cerrado.

La intimidad del correo personal tanto postal como electrónico esta amparada por la ley y la constitución
de la mayoría de los países.

CORREO CONFIDENCIAL UTILIZANDO PGP

PGP: PRETTY GOOD PRIVACY

PGP es un paquete completo de seguridad para correo electrónico. Presta servicios de encriptación,
autenticación, firmas digitales y compresión de datos. Todo el paquete se distribuye de forma gratuita,
incluyendo el código fuente. Es posible conseguir PGP en Internet para varias plataformas incluídas Unix,
Windows y MacOS.

Debido a las restricciones impuestas por el gobierno de los Estados Unidos a la exportación de sistemas
de encripción, PGP ha sido el foco de diversas controversias. Además de otros conflictos con relación a
patentes del algoritmo RSA.

PGP utiliza algoritmos existentes de encripción, en vez de crear unos propios. Estos algoritmos son: RSA,
IDEA y MD5. También PGP soporta compresión de texto, utilizando el algoritmo ZIP.

Para enviar un mensaje encriptado y firmado, ambas partes deben tener el software PGP e intercambiar
sus llaves públicas. El proceso es el siguiente:

Supongamos que Sutanito quiere enviar un mensaje firmado a Menganito de forma segura (encriptado).
Tanto Sutanito como Menganito tienen llaves privadas (Dx) y llaves públicas (Ex). Es necesario que
ambas partes conozcan la llave pública del otro.

Sutanito empieza su programa PGP en su computador. PGP aplica un algoritmo de hash al mensaje en
texto plano (P), este algoritmo es MD5. Se concatena P con el hash y se obtiene P1. El resultado es
comprimido con el conocido algoritmo Ziv Lempel, obteniéndose P1.Z. Ahora Sutanito escoge una frase
que será utilizada por el programa PGP para generar una llave aleatoria, dependiendo del texto escrito y
la velocidad de escritura, se Obtiene Km, esta llave se utiliza para encriptar P1.Z con el algoritmo IDEA,
Km a su vez es encriptada con la llave pública RSA de Menganito. Se concatena la llave Km encriptada
con el resultado del algoritmo IDEA y finalmente se convierte a Base 24. El mensaje a transmitir por la
red solo contiene caracteres alfabéticos, dígitos y los caracteres +, / e =.

Cuando Menganito recibe el mensaje, revierte la codificación Base 24 y desencripta la llave IDEA (Km)
utilizando su llave RSA privada. Utilizando Km llega a P1.Z. Luego de decomprimirlo, separa el texto
plano del hash encriptado, desencripta el hash con la llave pública de Sutanito, Menganito aplica el
algoritmo de MD5 al texto plano y lo compara con el hash que obtuvo al utilizar la llave pública de
Sutanito, si son iguales, se puede estar completamente seguro de que el mensaje no fue alterado y que
quien lo envió fue efectivamente Sutanito.

RSA es un algoritmo lento, pero solamente es utilizado en dos pasos: para encriptar el hash MD5 y para
encriptar la llave IDEA. La encripción más pesada es llevada a cabo por IDEA que es más rápido que
RSA.

La parte de la firma contiene un encabezado. Al encabezado le sigue una estampilla de tiempo, el

identificador para la llave pública del que envía que puede ser utilizado para desencriptar el hash, alguna
información que identifica los algoritmos utilizados (tipos) y el hash mismo.

La parte del mensaje también contiene un encabezado, el nombre del archivo por defecto en caso que el
receptor quiera grabarlo en el disco, la hora de creación del mensaje y finalmente el mensaje mismo.

El manejo de llaves en PGP se hace mediante llaveros. Un usuario puede tener varios pares de llaves
para él, para permitir cambiarlas en caso de que sospeche que una llave ya no es segura, pero
permitiendo que los mensajes enviados recientemente puedan ser reconocidos. Estas llaves están en el
llavero de llaves privadas, que está protegido mediante una frase clave, en caso de que sea robado.

Un usuario tiene un llavero de llaves públicas, donde almacena las llaves públicas de sus amigos y de
aquellos con quien intercambiar correspondencia.

Se usa también para enviar ficheros a través de correo electrónico codificados en formato ascii y mucho
mejor que otros sistemas como el uuencode ya que el PGP usa antes de codificar una compresión zip,
como se indicó anteriomente, al documento o programa que va a codificar.

En SSL, la privacidad se logra a través de los algoritmos de encriptación. Existen dos tipos de encriptación,
simétrica y asimétrica (SSL utiliza las dos en cada sesión). En la encriptación se utiliza una clave para
convertir los datos binarios en una forma ilegible. En la
encriptación simétrica se utiliza la misma clave para convertir esos datos ilegibles a su forma original. La
clave es sencillamente un dato que se mantiene secreto – alguien que conoce o tiene acceso a esa clave puede
leer la información
encriptada. El problema de la encriptación simétrica es el de buscar el método adecuado para que un conjunto
de usuarios autorizados conozcan la clave. Es decir, existe un problema de distribución de la clave. Para
solucionar este problema surgieron los algoritmos de encriptación asimétrica.
La encriptación asimétrica se basa en la existencia de un par de claves, una pública y otra privada. La clave
pública puede ser conocida por cualquier
internauta, gracias a esto, se puede por ejemplo, enviar un correo electrónico a un compañero utilizando su
clave pública. Aunque alguna persona intercepte el mensaje, no podrá decodificarlo y leer su contenido porque
esto solamente se puede hacer con la clave que hace pareja con la pública y es la clave privada que posee el
destinatario. Tratar de averiguar esta clave privada que hace juego con la pública es extremadamente difícil.

Veamos un ejemplo. Supongamos que Borja quiere enviar un datos de manera secreta (privada), integra y
auténtica a Mónica. Para preservar estos tres aspectos de la seguridad utilizaremos encriptación asimétrica.
Para poder utilizar protocolos de encriptación asimétrica, ambos usuarios deben tener una clave pública y otra
privada. La clave pública de cada una de las partes debe ser conocida por ambos. Para ello se puede utilizar un
método convencional (correo,
tfno, fax, etc.) o un simple correo electrónico o un directorio público de claves públicas (tipo listín).

Para que los datos mantengan su privacidad, deben viajar encriptados. Por ejemplo, supongamos que Borja es
el emisor. Entonces cifraría el mensaje con la clave pública de Mónica (ver figura 22). Por su parte, Mónica
descifraría el mensaje con su clave privada. Notese que el proceso es muy sencillo, porque la obtención de la
clave pública es muy fácil.

En el proceso anterior se ha garantizado la confidencialidad pero no la autenticidad dado que cualquiera

podría enviar un mensaje a Mónica (su clave es pública haciéndose pasar por Borja). La solución está en el
mismo sistema de encriptación asimétrica. El proceso es el siguiente, Borja, antes de cifrar el mensaje con la
clave pública de Mónica para garantizar la privacidad, debe cifrar el mensaje con su propia clave privada. De
este modo, Mónica puede descifrarlo con la clave pública de Borja que es la única capaz de hacer juego con la
privada de Borja. Si la operación se completa con éxito, se garantiza la autenticidad de Borja. Posteriormente,
debe utilizar su propia clave privada para decodificar el mensaje.

El algoritmo de llave pública más conocido se llama RSA y se desarrolló a mediados de los años 70. Se basa en
la premisa matemática que es fácil multiplicar dos números, pero difícil encontrar cuáles fueron los números
originales, basándose en el resultado (esta operación se llama factorizar).
Todo el sistema de la doble clave está automatizado en el WEB. Cuando intentamos conectarnos con un
servidor seguro (identificado en la URL por https en lugar de http) como por ejemplo
https://www.dte.us.es/JAA, el servidor nos hace llegar la clave pública. El navegador, si admite SSL
(Netscape e IE lo hacen) recogerá la clave pública y la utilizara a partir de ese momento para negociar la clave
de sesión. El servidor la descodificará con su clave privada.

El navegador nos hará saber que la comunicación es segura mediante un mensaje.

El cliente también puede saber que la comunicación es segura por que en el navegador aparecerá un símbolo,
normalmente un candado cerrado.

Por último, una vez resueltos los problemas de privacidad y autenticidad, falta explicar el modo en que se
resuelven los problemas de integridad. Para ello se utilizan las funciones
Hash. Esta técnica se basa en dejar una “huella” en el documento. La huella está formada por información
(aproximadamente 128 bits) que se genera al pasar un algoritmo a un texto dado. La característica de la
función Hash es que genera una huella distinta para cada tipo de texto (o datos que se envían) de modo que si
alguien altera un solo bit de la información original del emisor, al tratar de reconstruir la huella en el receptor,
nos dará una huella totalmente distinta a la que viaja con el mensaje y que ha sido generada en el cliente.

La huella por supuesto debe viajar encriptada y firmada (autentificada) por el cliente para que nadie la
trampee. De este modo, se cifra del mismo modo que el mensaje con la clave pública del receptor y la privada
del emisor. Si solamente se busca integridad en el proceso, el mensaje no se debe cifrar pero la huella sí.

El punto más débil de todo el proceso que se acaba de presentar está en el modo en que Borja ha obtenido la
clave pública de Mónica. Se supone que Mónica se la comunicó por teléfono o que acudió a un directorio público
electrónico, pero imaginemos que alguien fingió la voz o suplantó al listín electrónico. Para asegurar que la
distribución de la clave pública sea fiable surgen las Autoridades de Certificación
(CA). Estas autoridades, al igual que todos los agentes del proceso poseen una clave pública y otra privada. No
obstante, todo el mundo conoce la clave pública de las CAs porque aparecen en prensa, radio, etc. Así,
cualquier servidor o persona física puede solicitar que la CA certifique su clave pública. Las CAs habitualmente
son los gobiernos de los países, los bancos, las cámaras de comercio, etc.

De este modo, la CA, lo que hace es asegurarse de manera más o menos fiable (física) de la identidad del
solicitante. Tras esto, firma la clave pública del solicitante con su clave privada (la de la
CA) gracias a esto, en el ejemplo, Borja podría adquirir la clave pública de Mónica cifrada por la
CA, al descifrarla mediante la clave pública de la CA sabría que la clave pública de Mónica es auténtica.
Certificados

Los certificados digitales (Digital ID) se utilizan para garantizar la autenticidad

de todas las partes en una transacción digital. En el modelo más simple de una transacción a través de Internet
intervienen el servidor que aloja la aplicación y el cliente que accede a la misma. La autentificación del lado
servidor mediante certificados digitales se presenta en un apartado posterior. En este punto presentaremos el
papel que juegan los certificados en el lado cliente cuyo funcionamiento es muy parecido al de los servidores.

El certificado digital consiste en una serie de datos codificados mediante encriptación asimétrica de clave
pública y clave privada. Los datos que guarda un certificado de cliente son principalmente los identificativos del
mismo (DNI, nombre, apellidos, clave pública, etc.)

Este certificado, lo utiliza el cliente para acoplarlo al navegador y a los programas de correo electrónico. Gracias
a él puede realizar operaciones que requieran que la identificación del cliente sea fiable. Para que el certificado
tenga validez debe ser expedido por una CA (Autoridad de certificación). Esta CA cifra los datos del cliente con
su clave privada de modo que los servidores o destinatarios de la información conocen y se fían de la clave
pública de la CA mediante la cual decodifican los datos del cliente y obtienen su identidad de manera fiable.

La necesidad de estos certificados de cliente se aprecia por ejemplo en el caso de una compra
on-line. Cuando un empresario monta una tienda en Internet, desea evitar a toda costa los fraudes. Uno de los
problemas que se puede dar es que cualquiera falsifique un número de tarjeta de crédito y su caducidad
(existen generadores automáticos) o que alguien se encuentre una tarjeta y la utilice de manera fraudulenta.
Los certificados digitales evitan este problema.

Los certificados se pueden combinar con Hash para obtener autenticidad e integridad. El proceso sería el
siguiente: El cliente pasa una función Hash a su orden de compra. A continuación, cifra esta clave con su clave
privada y envía la orden de compra, la clave Hash cifrada y el certificado al servidor. En este momento, el
servidor es capaz de descifrar el cifrado de la información Hash gracias a la clave pública del cliente que viaja
en el certificado y además sabe que realmente es del cliente. Tras esto verifica el Hash y lo compara con el que
le llega. Si esta validación es correcta, ya tienen la seguridad de que se preservan la integridad y la
autenticidad.

Los algoritmos de clave pública son mucho más lentos (tal vez 100 veces más lentos) que los algoritmos
simétricos. Por eso normalmente no se utilizan para encriptar datos, sino para negociar una clave aleatoria que
se utilizará por un algoritmo simétrico para encriptar la comunicación entre dos entes. Esta clave aleatoria se
llama clave de sesión y se desecha una vez completada la sesión de comunicación confidencial.

Para conseguir un certificado de cliente, La persona que desea el certificado debe ponerse en contacto con una
CA, como por ejemplo Verysign. Normalmente habrá que hacer una visita a una pagina web, rellenar un
cuestionario, y, evidentemente, pagar. La CA realizará algún tipo de comprobación de la identidad aunque esta
no será, ni mucho menos, tan exhaustiva como para expedir certificados de Servidor.

El certificado quedará automáticamente instalado en el navegador sin casi necesidad de interacción por parte
del usuario, mas que insertar una clave.