ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Certificados y Firmas Digitales

El cifrado de datos es un mecanismo que garantiza que nuestros datos, aun cuando puedan ser interceptados por otros, permanecerán seguros. Por otro lado, los Hash nos dan un mecanismo para poder garantizar la integridad de un mensaje. Fue hace ya tiempo cuando se pensó en una aplicación práctica sencilla de estas dos tecnologías, y comenzó a hablar de Certificados digitales. Pronto fue igualmente necesario el concepto de firma digital, un sistema de autentificar algo.

Una tecnología se crea fundamentalmente pensando en algo. Así, el fundamento del cifrado de datos es simple, que cuando un mensaje sea interceptado no pueda ser leído o comprendido por una tercera persona a la cual no está destinado. Pero esto no impide que el mensaje pueda ser modificado, deteriorado, falseado… Imaginar una carta postal que se escribe con “tinta invisible”. Alguien que la intercepte quizás no pueda leer el contenido real de esta, pero puede coger otra carta, rellenarla con la información que desee y enviarla de nuevo al destino de esta. La pregunta es ¿Como podrá el destino saber si dicha carta ha sido modificada? En el caso de la carta quizás con un sello, una firma… aquí el concepto será el mismo, y podríamos decir que el fundamento de un Hash criptográfico es precisamente la integridad.

A raíz de la necesidad tanto de proteger el contenido de los datos en las comunicaciones, como de autentificar el emisor y el destino, como garantizar la integridad del mensaje, se creó el concepto de “Infraestructura de Clave Pública” (PKI). Este concepto no es más que la aplicación práctica en las comunicaciones de los conceptos que hemos visto anteriormente (y alguno más que veremos en este capítulo): Hash, Cifrado Simétrico y Cifrado Asimétrico.

En este capítulo vamos a intentar comprender básicamente cada uno de los elementos que constituye una infraestructura de clave pública (PKI), y veremos como cada siguiente elemento se hace necesario para el correcto funcionamiento de todo el sistema:

  • Infraestructura básica
  • Certificado: Necesidad de asociación usuario/empresa – Claves
  • Firma: Necesidad de autentificación de todas las partes e integridad


Infraestructura básica

Vamos a intentar aplicar todos los conceptos explicados a un entorno real que deseamos que sea completamente seguro. Para hacer esto tenemos que tener una serie de consideraciones, tendremos que crear una infraestructura en la cual podamos aplicar y hacer viable nuestras necesidades. Hemos dicho que el objetivo será triple a la hora de desear crear un canal de comunicación seguro entre dos partes: El cifrado, la autentificación y la integridad. Empezemos por lo tanto por la primera de las partes, el cifrado.

Lo primero que deseamos es que nuestros datos sean interceptados o no por una tercera persona, esta no pueda acceder a ellos. Hemos dicho que para ello disponemos de dos sistemas muy buenos, el cifrado simétrico y el cifrado asimétrico. Cada uno de ellos tiene ventajas e inconvenientes. ¿Cual es más factible de usar? En principio vamos a pensar que el cifrado asimétrico por una razón muy simple: Además de ser más seguro tan solo requiere de un par de claves (publica y privada) para el número que sea de canales de comunicación a entablar. Realizar esto por medio de un cifrado simétrico sería muy costodo en cuanto a infraestructura, dado que ¿Como crearías una base de datos en la cual se pudiese almacenar cada usuario un número sin fin de keys asociada cada una de ellas a un usuario o entidad diferente? Sería impensable. En cambio mediante el cifrado por clave pública esto podría simplificarse, dado que tan solo es necesario hacer pública una sola key para todos los canales de comunicación posibles, no una para cada canal. En realidad el sistema actual usado es híbrido, pero esto se verá más adelante, para nosotros simplemente decir que se opta de momento por el cifrado asimétrico, en nuestro caso RSA.

Una vez definida la necesidad de un sistema de clave pública y las ventajas que esta nos aporta, aparece el primer problema: Distribución. Hemos explicado que el sistema de cifrado asimétrico es muy eficiente e increíblemente versátil, lo que encripta una key privada lo desencripta la pública, lo que encripta la pública lo desencripta la privada. De ahí la necesidad de que la clave pública sea exactamente eso: Pública. ¿Pero como podemos hacer que cualquier usuario del planeta pueda tener acceso a dicha Key? Aquí es donde comienza a crearse la verdadera PKI, de la necesidad de ir solventando los por menores del camino. La única forma de que cualquier usuario conozca nuestra key pública es disponer de bases de datos en las que se encuentren almacenadas las claves públicas de todos los usuarios. A esto se le conoce como repositorios de claves públicas. Ahora, cualquier usuario puede enviar su clave pública asociada a un correo electrónico, nombre, apellidos… Pero de forma pareja aparece la necesidad de algún control sobre dichas bases de datos. ¿Que sucede si una key ha sido comprometida o ya no es válida? Es necesario por tanto otro Repositorio , en este caso un Repositorio de Revocación de claves públicas. Con estos dos sistemas podríamos garantizar el funcionamiento correcto del cifrado de datos entre dos usuarios. Estos repositorios existen a día de hoy, la mayoría de ellos se encuentran sincronizados con los otros para que todos tengan los mismos datos. Por ejemplo podemos visitar uno de ellos:

Repositorio de Claves Publicas del MIT

En dicho repositorio podemos buscar cualquier cadena de texto, ya sea nombre, apellidos, correo electrónico o ID de la clave:

 

Type bits/keyID     Date       User ID

pub  4096R/B9A35B9C 2009-12-02 Carmen Mendes <cmendes@transnumeric.com>

pub  2048R/F4D68EB5 2009-11-07 María del Carmen Rodríguez Sardiña <mariadelcarmen@gens-osorio.es>

pub  1024D/9BC23DEF 2009-10-15 carmenalves (ola) <carmen.alves.05@formando.gti.pt>
...

Por supuesto si continuamos el link de la KeyID nos topamos directamente con la clave pública de Carmen:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.0

mQENBEuGtJwBCAD0EM6+cVCIrc2t5CLWhrdwPrTbb4ZbTAKuLjAjULl3K+/usQg7JT0Y+qL6
Z/eGB8krZgzzT77bQHKVAw7NeUZGSMDl+kSIT9k5gx/vWxdyuBUeJODkd7IldiGbW5yhGz92
0LGbQ5weF2GT8DewCtawOsO46baygPIgiVR99vArzNyiX+KFnrUaniVbjbiN8KQY9Nvmdvyz
BU77W5SDRc4LbuOv5GCtnPKjlVQE5JApoelpZi2fiJkH/kKcf4ZTc0nSK8e8duHYB+zrKrxO
ICKHWXWgLBV9aZkoCH35oShK3JpSeimnV3yqwqz2zt32p/JNKO02krPNNIUL+AqVivEfABEB
AAG0SmNhcm1lbiByZXF1ZWpvICh1biBhbWlnbyBtaW8gc2UgbXVyacOzIGNvbmdlbGFkbykg
PGZvMjAxMGNhcm1lbkBnbWFpbC5jb20+iQE+BBMBAgAoBQJLhrScAhsjBQkJZgGABgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBeKv2mzKxFxS0wCACcC6fWZ9IliyKHI8gZBEl3s9Sd
WWlUJo/PNgbzEoq3N/aiy47+ITo/Qax9+PXYUUOH6Zx+CLb4NMyplSo3cESDlg4O/hzkypP6
9Yj6JflHQcqmWfGsWwqf3kiGSWopd8osKdb5bpvKfXI+JKc8Gj5l64JUa0f6BIPIL3/9/Uci
EhnEyHG0b2gJx/f3bybAG+mpBo3VnV/alTfZbX8qnen3Rqg1TPxEyfJjR6E4QrSkeHb8MJp9
ZGO58IWvWAPADJJoK2alKJMRKjeZKFjqcolr4mgNhRhg3iD77SmL1hskwfCinPXGnmimV/Xl
VH0qTX/4Jem6aTG+9aD8u8r3p4LyuQENBEuGtJwBCADALhMeR4PFXzKcxDUzn5yWbckFrz97
ONCbL1C0G/4Wg8fV3t0Vchzg6aKsEYUZSfTe5Ph0rqLWs1cfjgMxrCRYTfzmCffIWBmXixu7
iDuj6bRshY+9F03xFA0X/GJG1bZ/3JuIYTP804UU1/OsH+cFsyj1CnoUNz1zZ5rvm/76VqL1
vBskTyD7cfEPrSTh5HfBu8EatdI0rCPezyzZeE0IhWYg7OChBK6FzkaIEZifpxI7/KSadPNw
NLO0WdLmFhqLqS/Pwt4oCcMxljB9zoO/KGRyvw4nY6BilItFwaIfOjDbrVqDSnG9RZ8+Cevo
TfPi1j1VsBpc113vMqs0g14hABEBAAGJASUEGAECAA8FAkuGtJwCGwwFCQlmAYAACgkQXir9
psysRcVvjgf9F0o3Q3/MbLMriwe9naCXuy2xcceWyZ9vp6ZPm5zoD1Tt7aWRBeFUhk/T88sa
SqcpVqZSNtsdjJl7oHXVcFKeccIebOs826GIMzWgT6kCl2r79RY4W7b0iaPzljH7ayX7Ce3Z
UM7Z0JhCmjH6aszc/dXd3JkHR9cxiY9A1HWrgGzd2RlNCYOVB1kokteVE9+CXCyJwAelSCLR
GAYl33oyxGDKxngVCdeBRxgCeTU0szL7NXMNi3Y2cQCHCiEwTspKXS+wOtos66vgYLYXdgJs
KvW0gau6bUwBouD7aXZOkubfpZ3J85X6KcLuPAQfJlhtuufimJ3y7/+B09c0TD+Osw==
=PqHr
-----END PGP PUBLIC KEY BLOCK-----

Ana desea enviar un mensaje cifrado a Carmen:

a) Ana accede a un Repositorio de Claves pública para obtener la Clave pública de Carmen, para ello busca en la base de datos por “Carmen”. Es posible que haya más de una (puesto que alguna puede estar revocada)
b) Ana con la clave en su poder verifica que esta key no se encuentre en la lista de Revocación. Dado que no está, considera que la key está en uso y es válida.
c) Ana encripta el mensaje con la clave pública de Carmen y le envía el mensaje
d) Carmen desencripta el mensaje con su clave privada.

De este modo Ana puede enviar un mensaje cifrado a cualquier usuario del mundo que esté usando un sistema de clave publica, sin necesidad siquiera que el emisor use dicho sistema, y con la garantía de que dicho mensaje tan solo podrá ser desencriptado por el poseedor de la key privada pareja a la key pública del repositorio. Este sistema logra el objetivo del cifrado de datos. ¿Pero que sucede ahora con la autenficicación?

En el ejemplo expuesto, Ana no puede asegurar de ninguna forma que la clave pública obtenida del repositorio accedido proceda de “Carmen”. Sí, es posible incluso que en dicho repositorio quedase indicado nombre, apellidos, dirección, DNI… pero dado que son repositorios a los que todos tienen acceso, cualquiera podría introducir datos falsos en ellos. Por ejemplo, podría crear una key publica/privada a nombre de otra persona, de esta forma cuando alguien quisiese enviarle a dicha persona un mensaje, lo encriptaría con mi pública. Aquí es donde nace la necesidad de autentificación, de algún sistema por el cual Ana pueda estar convencida que la clave pública obtenida pertenezca a Carmen. Para esto se opta por dos sistemas diferentes, aunque ambos se basan en la misma premisa: Cadena de confianza.

Imaginar que de algún modo se pudiese dar un punto positivo a una clave pública, de forma que cuantos más puntos positivos tenga una Key pública de un repositorio indicase a terceras personas que dicha key es válida. Así por ejemplo yo podría dar un punto positivo a la clave púplica de mis hermanos, puesto se fehacientemente cual es la que pertenece a cada uno de ellos. De este modo, si una tercera persona desease enviarme un mensaje cifrado a mí, se fiaría en caso de duda más de aquella clave pública que tenga más puntos positivos de personas diferentes. Ahora imaginemos que Ana desea enviar un mensaje cifrado al mismísimo Linus Torvalds (El cual espero no le importe que use su nombre para estos ejemplos) para consultarle un bug crítico en el kernel de linux. Lo primero que haría sería acceder al repositorio y buscar por “Linus Torvalds”, dado que ni siquiera conoce su correo electrónico. El repositorio le devolvería lo siguiente:

Type bits/keyID     Date       User ID

pub  1024D/825D2E82 2008-09-03 Linus Torvalds (Teste) <linus@linux.org>

pub  1024D/D080B7A0 2008-07-26 *** KEY REVOKED *** [not verified]
                               Big Gay Al (kay) <letsseesomelove@love.com>
                               REVOKED KEY (u suck) <FUNBO@T>
                               Linus Torvalds (revoke revoke revoke) <werfsdfasdf@fakefakefake.com>

pub  1024D/006D1B6D 2005-11-11 *** KEY REVOKED *** [not verified]
                               Danilo G. Magrini <danilo.magrini@gmail.com>
                               Danilo G. Magrini <danilomagrini@uol.com.br>
                               Danilo G. Magrini <danilo@onclicksistemas.com.br>
                               Danilo Gustavo Magrini (Linus Torvalds) <danilomagrini@uol.com.br>

pub  1024D/8BC6EDEF 2005-11-10 Danilo Gustavo Magrini (Linus Torvalds) <magrini_sp@superig.com.br>

pub  1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

pub  1024D/CE904A82 1999-11-21 Linus Torvalds <vnixroot@netscape.com>

pub  1024D/449FA3AB 1999-10-05 Linus Torvalds <torvalds@transmeta.com>

pub  1024R/A86B35C5 1996-06-08 Linus Torvalds <Linus.Torvalds@Helsinki.FI>

 

Ana es una chica lista, pero según el repositorio existen 8 posibles claves públicas supuestamente todas correspondientes al bueno de Linus. Sin dificultad Ana descartaría de forma automática las que están marcadas como Revocadas, lo que deja el listado con 6. La primera se podría descartar dado que aunque el correo podría ser legítimo, pone (Test)… podemos imaginar que fue creados con fines de testeo, además, la fecha de la clave es relativamente nueva. La cuarta la excluimos porque el nombre ni siquiera pertenece al de Linus. De este modo tan solo nos quedarían como posibles las 4 últimas. la quinta no obstante puede leerse como (tag signing key) que podríamos suponer que se trata de una clave tan solo para firmas (esto se verás más adelante), así que de momento la descartamos también. Las otras tres restantes podría parecer legítimas a simple vista. Como Ana quiere asegurarse, quiere ver lo que hemos llamado como “votos positivos” de ellas. Si accedemos a la sexta obtenemos la siguiente información:

pub  1024D/CE904A82 1999-11-21            

uid Linus Torvalds <vnixroot@netscape.com>
sig  sig   CE904A82 1999-11-21 __________ __________ [selfsig]
sig  sig   8061A830 2005-05-30 __________ __________ Dan Mundy <harob02@earthlink.net>

sub  2048g/1EEE5A92 1999-11-21
sig sbind  CE904A82 1999-11-21 __________ __________ []

Los votos positivos que hemos nombrado en realidad son firmas, dado que aun no hemos hablado de ellas tan solo imaginamos que son algo así como voto de confiabilidad. En este caso vemos que tan solo posee una firma creada por él mismo “selfsig” y otra firma (voto) creado por un tal Dan Mundy. Ana, que no es tonta, imagina que una persona como Linus, de tener una clave pública en estos repositorios tendrá seguro bastantes votos de confiabilidad. Luego la rechaza.

Esto deja a Ana con dos opciones, las dos últimas. Ana conoce un poco la vida de Linus y le suena que trabajó o tubo relación con trasmeta.com, luego parece un buen punto de partida. No obstante sabe también que Linus es finlandés, nacido en Helsinki, lo que quiere decir que las dos claves que aparecen podrían ser completamente legítimas. Y en este caso las dos pertenecen a él. No obstante, si nos adentramos en la última de ellas, generada nada más y nada menos que en 1996!!, esto es lo que obtenemos:

pub  1024R/A86B35C5 1996-06-08 __________ 

uid Linus Torvalds <Linus.Torvalds@Helsinki.FI>
sig  sig   A86B35C5 1996-06-08 __________ __________ [selfsig]
sig  sig   2A960705 1997-04-24 __________ __________ H. Peter Anvin <hpa@zytor.com>
sig  sig   29BC0185 1998-01-24 __________ __________ george a. r. hill <9x>
sig  sig   0C00E6AD 1998-08-21 __________ __________ Alexander Smith <Sabin84@usa.net>
sig  sig   CCBEA8D2 1998-09-02 __________ __________ Kenyon Ralph <kenyon@san.rr.com>
sig  sig   ACF5A545 1998-12-17 __________ __________ H. Peter Anvin <hpa@zytor.com>
sig  sig   A4679654 1999-01-30 __________ __________ Drizuid <drizuid@drizuid.net>
sig  sig   F0C36E09 1999-01-30 __________ __________ Drizuid <dark-druid@geocities.com>
sig  sig   29B0C351 1999-06-18 __________ __________ Jens S�lwald <j.suelwald@gmx.de>
sig  sig   FEEFE90B 1999-09-15 __________ __________ []
sig revok  FEEFE90B 1999-09-15 __________ __________ []
sig  sig   6470AB26 2000-03-02 __________ __________ Cedric Blancher <cblancher@cmc.fr>
sig  sig   A4C70528 2000-03-15 __________ __________ Alexander Smith <sentinel@freshshell.de>
sig  sig   A24D8B4E 2000-08-10 __________ __________ C�dric Blancher <cblancher@startem.net>
sig  sig   24901EE8 2001-05-31 __________ __________ Simon A Soanes <simon@nullifynetwork.com>
sig  sig   9CD30D3D 2001-10-09 __________ __________ ZC Wong <zcwong@hotmail.com>
sig  sig   01B45CE2 2001-10-09 __________ __________ ZC Wong <zcwong@hotmail.com>
sig  sig   D925418D 2004-04-18 __________ __________ Kevin W. Peters (Guitarman) <guitarman@ntdf.com>
sig  sig   6422D07C 2004-05-23 __________ __________ Fabian Foerster (Root CA) <fabian_foerster@web.de>
sig  sig   0C877B34 2004-05-23 __________ __________ The Root Networks (Root CA) <root-networks@web.de>
sig  sig   FA81F1E6 2004-06-14 __________ __________ Thomas Shea <lrmm@comcast.net>
sig  sig   AAE6022E 2004-12-28 __________ __________ Karlheinz Geyer (RBOS) <karlheinz.geyer@lhsystems.com>
sig  sig   4D34B354 2004-12-28 __________ __________ Karlheinz Geyer (DKB) <karlheinz.geyer@lhsystems.com>
sig  sig   8061A830 2005-05-30 __________ __________ Dan Mundy <harob02@earthlink.net>
sig  sig3  099A79AC 2005-07-12 __________ __________ Konstantin Vinakovsky <kvinakovsky@earthcam.com>
sig revok  AAE6022E 2005-07-28 __________ __________ Karlheinz Geyer (RBOS) <karlheinz.geyer@lhsystems.com>
sig revok  4D34B354 2005-07-28 __________ __________ Karlheinz Geyer (DKB) <karlheinz.geyer@lhsystems.com>
sig  sig   6BEEAF8D 2008-08-02 __________ __________ Kristoffer Warming <heavyhenning@gmail.com>

 

Ana comprende que efectivamente no solo ese puede ser un correo válido de Linus, sino que también lo es su clave pública. Puede comprobar que tiene una serie de firmas en su clave que de un modo reafirman que dicha clave pertenece a él. Se puede observar que 3 de las firmas (votos) están igualmente revocados, pero aun así parece claro que esta es una clave válida y legítima. La última forma pertenece a 2008, lo que nos puede hacer pensar que la cuenta está aun en activo.

pub  1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

Pertenece también a él, es un correo que es más que conocido por programadores y otros que frecuentan listas de correos del kernel de linux, lo que sucede es que aparentemente por ese nombre podemos deducir que Linus la usa tan solo para firmar, y no para encriptar (esto se verá como he dicho más adelante)

Llegados a este punto, Ana ha logrado dos objetivos. El primero cifrar los datos y el segundo asegurarse que dichos datos están cifrados efectivamente y tan solo para Linus Tolvards, gracias al anillo de confianza que generan estos votos (que no son sino firmas digitales). Pero aun le queda a Ana un problema. La integridad. Como puede estar Ana convencida que el mensaje que reciba Linus no haya sido modificado por un tercero. Ana desea que en el peor de los casos y que este haya sido modificado, Linus pueda conocer que este ha sido modificado, así pueda contactar de nuevo con Ana y solicitarle de nuevo el envío del mensaje legítimo.

Después de un rato de meditación, Ana recuerda la funcionalidad del Hash criptográfico. Ana no podrá garantizar nunca que el mensaje llegue sin modificación alguna, pero puede garantizar que de ser modificado Linus se percatará de ello. ¿Como? Ana recuerda que si aplica por ejemplo un Hash SHA-1 al mensaje cifrado y envia tanto el hash como el mensaje cifrado, Linus podría verificar si el hash especificado por Ana y si coincide con el Hash real del mensaje. Una tercera persona sino, podría interceptar el mensaje, crear un mensaje nuevo, cifrarlo con la key Pública de Linus y enviárselo en nombre de Ana. No obstante, según este esquema una tercera persona podría igualmente interceptarlo, y como conoce el Hash que ha usado Ana, tan solo tendría que redactar el mensaje, encriptarlo, calcularle el nuevo Hash y enviar los datos a Linus. Es aquí donde aparece la necesidad de la firma digital.

Ana ha comprendido las técnicas de los hackers que quieren modificar su mensaje cifrado (sin saber siquira que hay dentro de dicho mensaje) así que ha descubierto la solución definitiva. Ana, que también tiene usa sistemas de clave pública tiene su propia clave pública y privada:

a) Ana redacta el mensaje y lo encripta usando la clave pública de Linus
b) Ana calcula un Hash SHA-1 al mensaje encriptado y este mismo hash lo encripta con su clave privada (A esto se le llama firma digital)
c) Ana envía tanto el mensaje cifrado como la firma a Linus.
d) Linus accede al repositorio de claves públicas y busca la correspondiente a Ana y a dicha dirección de correo (del mismo modo que hizo Ana). Encuentra la que busca con muchos “votos” a su favor, y con la clave pública de Ana es capaz de desencriptar el hash de Ana. Linus calcula el Hash SHA-1 al mensaje cifrado y verifica que ambos valores coinciden!! Luego el mensaje ha conservado su integridad y tanto Ana como Linus han sido autentificados el uno al otro y establecido un canal seguro cifrado.

Si un tercero intentase de nuevo interceptar el mensaje de Ana, cualquier cambio que produjese en él destruiría el hash del mensaje, Linus al descifrar el Hash de Ana comprobaría que este no coincide con el Hash del mensaje, luego comprende que el mensaje ha sido comprometido y rechaza la comunicación. El atacante podria redactar un nuevo mensaje, cifrarlo, calcularle el hash y firmarlo (encriptarlo con su clave pública), pero entonces Linus sabría perfectamente que la clave pública necesaria para desecifrarlo no correspondería a la Ana!! Sino a la del atacante, con lo que jamás la aceptaría. Es aquí donde radica la importancia del círculo de seguridad, la necesidad de saber fehacientemente que una clave pública pertenece a quien dice pertenecer.

Este esquema PKI es básicamente lo que se lleva a cabo en los sistemas de clave pública PGP/GPG, pero ahora veremos las herramientas para el esquema SSL/TLS.

 

Certíficado Digital

Ahora sí es la primera vez que lo nombramos. Un certificado digital no es más que un documento, un archivo que identifica/asocia a un usuario con su clave pública. Cuando veíamos los repositorios de claves públicas y realizábamos una búsqueda, cada entrada tenía asociada un nombre, descripción, clave pública y firmas (los votos que hablábamos) de verificación de otras personas. Un certificado es lo mismo (con algunos matices).

El esquema PKI anterior (llamado Web of Trust) tiene el problema de la confianza, de la legitimidad. Es un buen paso hacia delante el firmar las claves ajenas para avalar su legitimidad, y está bien para trámites particulares, personales, encriptar archivos, correos a familias y amigos… pero si una organización mundial, un gobierno, un particular o una empresa quieren garantizar que dicha clave pública pertenece sin lugar a dudas a quien dice pertenecer, es necesario un sistema más fiable. Es aquí donde aparece la “Autoridad de Certificación” (CA). Se van a continuar firmando los certificados sí, pero no por cualquier persona o grupo de ellas. Un certificado Digital asocia una serie de datos personales a una clave pública, y será un tercero, llamado Autoridad de Certificación, quien garantice que esos datos corresponden a dicha clave pública. Visto de otro modo, se trata de eliminar todas las firmas y sustituirla tan solo por una, una entidad, empresa, gobierno… cuya firma tendrá mucho más valor que cualquier otra, dado que posiblemente se ha encargado previamente de verificar y asegurar que los datos son correctos.

Los CA de máximo nivel se les llama CA raíces o root. Existen CA que delegan autoridad a otros CA secundarios para permitirles otorgar y firmar otros certificados. Esto se debe a la cadena de confianza. Yo como máxima autoridad certifico a una empresa como CA secundaria de la cual tengo plena confianza, permitiéndole emitir y firmar certificados a ellos mismos. Si cualquiera quiere verificar un certificado emitido por un CA secundario o terciario, se realizará una verificación ascendente, primero al CA superior, el certificado de dicha CA se verificará por el CA por encima… hasta llegar al CA raíz, el cual emite él mismo su propio certificado.

Los CA son los que emiten los certificados, y al firmarlos les otorgan plena legitimidad dado que todos nos fiamos de ellos, dado que son la máxima autoridad de certificación. Podemos decir que los CA son también esas bases de datos de claves públicas/certificados de cada usuario. Pero el CA no es la única autoridad que existe. Por otro lado suele ser necesaria (no obligatoria) la presencia de la “Autoridad de Registro” (RA). El papel de un CA puede acabar aquí, y encargarse tan solo de la emisión y firmado. Muchas veces cuando se desea cotejar/verificar si un certificado es correcto, es el RA quien se encarga de verificar dicho certificado, siendo él el que conecta con el CA. Otra figura menos usada es la “Autoridad de Validación” (VA), la cual tendría un papel similar, verificar si el certificado es válido atendiendo a fechas de tiempo y otros datos. Aun así, como digo, lo normal es ir unificando las autoridades de verificación, y de paso las comunicaciones son más eficientes. Así el mismo CA actúa como RA y como VA. Hace unos años los CA raíces eran muy pocos, lo que hacía muy útil estas autoridades intermedias. Cada vez son más los CA raíces y los sistemas más eficientes, siendo innecesaria la presencia de otras autoridades intermedias. Muchos de los lectores conocerán el nombre de algunos de ellos, actualmente el listado de CA raíces debe de rondar las 90 entidades (sin contar con los CA estatales, como CA de países, aunque estos no suelen considerarse como “universales”. Entre ellos los más importante con diferencia son: VeriSign, Thawte, GoDaddy, GeoTrust, RSA Security Inc (la empresa)…

En los tiempos actuales, no es raro ver como gobiernos, grandes instituciones o multinacionales están considerados también como CA, lo que sucede es que normalmente estos CA no emiten certificados a cualquier persona. Por ejemplo, el gobierno español tiene al menos dos Autoridades de Certificación, la FNMT (certificados CERES) y La dirección General de Policía (Certificados para el DNI-e). Pero estas dos instituciones tan solo emiten certificados a los que tenemos nacionalidad española. Otro ejemplo de esto podría ser Intel o Microsoft. Ambos están considerados como CA raíz, pero no se dedican al negocio de los certificados digitales. Esto le permite a estas grandes multinacionales no depender de terceros, ahorrar costes y gestionar ellos mismos sus propios certificados, aunque evidentemente tan solo usan dichos certificados para ellos mismos, sus servidores, sus empleados quizás… por eso podemos dividir estos dos grandes grupos como aquellos CA comerciales y aquellos que no lo son.

Con esto, el esquema anterior PKI se modifica ligeramente y es el CA, el RA o el VA quien valida o garantiza la legitimidad del certificado.

Hay que destacar que no existen dos certificados, uno que sea público y otro que sea privado. El certificado es tan solo el vehículo de la clave pública. Es cierto que los certificados personales almacenados en el equipo se “guardan” con la clave privada junto a este, lo cual es completamente lógico, puesto que sin clave privada no podríamos firmar o desencriptar. En realidad esto no es del todo cierto, dado que las claves privadas de estos certificados suele estar guardadas en un anillo de seguridad del sistema/equipo. Esto no obstante ocasiona un problema de seguridad importante dado que si alguien se hace con la clave privada, el sistema quedaría completamente expuesto. Es por ello que cuando se requierer una seguridad avanzada, tanto certificados personales como las claves privadas, jamás serán almacenados en un equipo, sino en soportes extraíbles como un pendrive (en el peor de los casos) o una SmartCard (Tarjeta Inteligente) en el caso ideal, o incluso un dispositivo TPM. Esto quiere decir que nuestra clave privada residirá en nuestro DNI-e o tarjeta CERES o… protegida además por un PIN por si es extraviada o sustraída. Cuando se requiere su uso es necesario un lector de tarjetas y el software adecuado para tomar de esta la clave privada y el certificado.

El Certificado no solo indica el nombre y apellido de quien representa, sino que incluye información del CA que lo ha emitido, algoritmos de cifrado y hash que usa, fecha de revocación, validez, tipo de certifiado… toda esta información es necesaria. Por ejemplo el certificado de identificación o cifrado de un servidor no tiene nada que ver con un certificado de cliente que podamos usar nosotros, o el certificado raiz de un CA es diferente a los otros dos. Por otro lado no todos los certificados se emiten para todos los propósitos. Lo normal es emitir los certificados con ciertas características. Por ejemplo, si se desea usar un certificado para cifrar correo electrónico será necesario que el certificado especifique una dirección de correo, y este certificado quedará anclado a él. Otro buen ejemplo es un certificado con unas características concretas para el control de acceso de una empresa o para cifrar datos en un equipo. Así, nuestro DNI-e por ejemplo tiene dos funciones principales, autentificación y firma (hablaremos más detenidamente del DNI-e en otro capítulo).

Vamos a ver unos certificados de ejemplos: Un certificado de un servidor para SSL/TLS (Gmail), un certificado CA raíz (VeriSign) y un certificado personal para identificación SSL/TLS, firma y cifrado de correo que no de datos (Mi Certificado CERES):

Hay que decir que estos datos son totalmente públicos, cualquiera que acceda a gMail o descargue el certificado de gMail podrá verlo. Firefox divide el certificado en dos pestañas. La primera es un resumen sobre el emisor, a quien representa y si el certificado es válido para los propósitos marcados (en este caso el propósitos es para un servidor SSL). Recordar que cada vez que un certificado es usado, lo normal es verificarlo. ¿Cómo? Verificando la firma de la entidad firmante. Podemos ver en la primera pestaña que el emisor es Thawte (que es el CA de dicho certificado), que está a nombre de Google Inc para la web mail.google.com (gMail). Se puede ver también la fecha, que aunque no hemos hablado de ella es importante, ya que cuando se emite un certificado este suele tener un tiempo limitado. Tras el cual, el certificado pasa a ser revocado (anulado) y se emite otro (normalmente antes de que expire) con nuevas claves privadas y públicas, esto se hace por seguridad evidentemente.

La segunda pestaña desglosa completamente el contenido del Certificado. En caso de este certificado, Firefox nos muestra en la parte superior la jerarquía de CA que intervienen en dicho certificado, es decir la cadena de confianza. Así, el certificado de google para mail.googl.com es emitido por el CA “Thawte SGC CA”. Este CA no es un CA raíz, sino un CA secundario. El certificado de este CA a su vez es el que ha sido emitido por el CA raíz “Verisign Class 3 Pubblic…”. Por último se muestra la clave pública contenida en dicho certificado.

 

El primer certificado pertenece a un certificado raíz de VeriSign, el mismo que estaría arriba del todo del certificado de gMail para la web. En este caso el uso que se indica es el de “Status Responder Certificate”. Es decir, tan solo es usado prácticamente para atender a las peticiones OCSP que pueda recibir de sus CA secundarios, es decir… verificar si los certificados están o no revocados. En este caso no se considera un CA dado que el papel de verificación de CA lo realizará el CA que esté a su servicio. Este certificado raíz fue el que emitió/validó el certificado de “Thawate SGC CA”, y es este último quein actuó realmente como CA del certificado de mail.google.com. El certificado CA intermedio será por tanto realmente el que en su descripción de uso rece: “SSL Certificate Authority”, puesto que el certificado Raíz tan solo atiende a peticiones de revocaciones. Se puede observar que efectivamente es un certificado raíz dado que el emisor (Issued By) y el destino del certificado (Issued to) no se encuentran presente, es él mismo emisor y destino, está firmado por él mismo.Si vemos la fecha por otro lado de expiración, vemos un intervalo muy grande, un certificado ahora con más de 14 años de antiguedad, que usa un algoritmo de hash MD2, un hash ya muy antiguo.

Por último tenemos un certificado de CERES. He preferido poner este en vez del DNI-e porque este es más útil, tanto y cuando además de poseer las características de autentificación en internet (Cliente SSL), permite también la firma de correo (Email Signer) y su Encriptación (Email Recipient). Podemos ver que el emisor es la FNMT, y dado que mi navegador tiene instalado el certificado Raíz de estos y considerado fiable, el certificado de CERES lo es también, podemos leerlo arriba: “This Certificate has been verified…” Por motivos de seguridad he eliminado mi nombre, DNI y esas cosillas.

 

Firma Digital

En realidad poco más o menos ya se ha comentado que es y cual es su utilidad. Cuando explicábamos una PKI, exponíamos que cada clave pública se “votaba” para que los otros usuarios pudiesen así garantizar que era legítima. Esto es realmente una firma. Una firma tiene la característica de no repudio, es decir, una vez se ha firmado algo un usuario o una entidad no puede desquitarse de ello, dado que la firma lo identifica a él de forma irreversible, sin que este pueda negar que lo ha hecho.

Las firmas digitales usan de forma conjunta dos tecnologías, la inviolabilidad de un sistema de cifrado asimétrico tipo RSA y la integridad de datos que ofrece un Hash criptográfico como SHA-1 o MD5. Si un usuario desea cifrar un documento o un mensaje para que tan solo podamos ser capaces de descifrarlo nosotros, tan solo tiene que cifrarlo con nuestra clave pública, y tan solo nosotros poseedores de nuestra clave privada podremos descifrarlo. Pero esto puede usarse de manera inversa. Si yo cifro algo con mi clave privada, la clave pública lo descifra. Dado que todos tienen acceso a mi clave pública, todos pueden descifrar aquello que yo cifre con mi clave privada. ¿Pero entonces para que vale esto? Porque un certificado garantiza la asociación de una clave pública a una persona física. Luego quien descifre algo con mi clave pública obtendrá un contenido que tiene la certeza fue cifrado solo por mí. Y por parte del Hash, otorga integridad al mensaje. El proceso es simple:

a) Se calcula un Hash criptográfico al mensaje, documento… a firmar, por ejemplo un Hash SHA-1.
b) Ahora se encripta por medio de nuestra clave privada dicho Hash, lo cual obtenemos un Hash cifrado.
c) A partir de este momento, al documento se le incrusta (adjunta) la firma. El destinatario, se topará con que existe una firma de dicho documento, con su certificado público correspondiente, y por supuesto con las validaciones pertinentes. El destinatario puede descifrar el hash y obtener el Hash que aseguró el remitente que era el idóneo. El destinatario calcula el mismo Hash al mensaje recibido. Si los dos Hash coinciden, el destinatario comprende que el mensaje es legítimo y que no ha sido modificado de ningún modo.

Una forma digital puede usarse para varias tareas. Por ejemplo, evidentemente como sustituto natural de nuestra firma física. No obstante ya hemos hablado que se usa para los certificados. Los certificados que nos emiten los CA deben de estar firmados por estos. La firma de estos en nuestro certificado funciona del mismo modo. Cuando se verifica un certificado, entre otras cosas como comprobar la fecha de validez o las listas de certificados revocados, se verifica que la cadena de confianza es correcta. ¿Esto que implica? Ir verificando uno a uno todos los certificados implicados en un certificado. Esto es verificar la firma del firmante de nuestro certificado, lo cual para ello es necesario verificar que el certificado de este CA está firmado por otra CA que sea igualmente válido… así hasta llegar al CA raíz. Si en cualquier lugar de la cadena falla la verificación, la cadena entera se rompe y el certificado no puede garantizarse como seguro.

Otro uso común es la firma de un código. Esta es una práctica cada vez más expandida en el mundo del software. Un método de proteger un sistema operativo frente a ataques, como pueda tener Windows Vista o Windows 7, es que los drivers deben de estar firmados obligatoriamente por Microsoft (en este caso), de forma que esto garantiza que los drivers no son dañinos y son legítimos. Esto puede verse también en las partes más críticas del sistemas, en las que los archivos o el contenido más sensible para el correcto funcionamiento del sistema se firma de forma que el propio sistema no permite su ejecución si la firma no es válida. El problema que ocasiona esto no obstante es que se puede hacer un uso intensivo de esto para evitar la libertad. Por ejemplo el iPod Touch/iPhone, en el que cualquier contenido que se desee ejecutar, debe de estar obligatoriamente firmado por Apple, si no lo está no se puede ejecutar. Esto implica que (sin JB) tan solo las aplicaciones aprobadas del AppStore pueden ser usadas, al margen de que pudiese ser posible o no instalar otro tipo de aplicaciones, al margen del degradamiento de rendimiento por tener que estar continuamente verificando las firmas. Desde mi punto de vista la diferencia del buen uso y el abuso es la intencionalidad. Proteger con una firma una bios o un bootloader tiene un sentido muy simple, es una parte crucial del sistema y cualquier virus o modificación dañina produciría que el sistema sea inutilizado, lo cual implica que es positivo. Pero debería de ser una opción, no una obligación. Por ejemplo, se dijo mucho sobre los drivers de Windows x64 y que nadie podría crear drivers para ellos dado que todos tienen que estar firmados por Microsoft. Esto no es tampoco tan así. Se pueden instalar drivers firmados por uno mismo si se quiere, lo que pasa es que el sistema nos advertirá sobre la procedencia del certificado y categorizará el driver como no seguro, avisándonos del peligro que ello implica. Pero a fin de cuenta la libertad es del usuario.

Lo habitual por tanto es ver una firma digital como un documento adjunto en un correo (extension p7s), incluida en el mismo cuerpo del mensaje en el caso de usar PKI como PGP/GPGo como un “añadido” a un documento. Al final del todo veremos aplicaciones prácticas de todo ello de todas estas cosas. De cara a un gestor de correos o cualquier otro programa que acepte contenido firmado, simplemente sabrá como interpretarlo y verificar dicho contenido.

 

Visto todo esto podemos hacernos una imagen de lo que es un certificado digital y la firma electrónica:

a) Ana descarga el certificado de Carmen, lo ha descargado del servidor LDAP de la empresa (o de la web de Carmen). Al instalarlo en su equipo (y sin que ella lo sepa) el certificado de carmen es comprobado. Dado que el certificado de Carmen está firmado por VeriSign, el equipo de Ana tan solo tiene que verificar que la firma de VeriSing es válida. Dado que el certificado raiz de VeriSign está incluido en el equipo, el equipo de Ana desencripta la firma de Verisign del certificado de Carmen con la clave pública que se encuentra en el certificado raiz de VeriSign. El equipo de Ana obtiene así el Hash del certificado de Carmen, el cual coincide a la perfección con el propio certificado, luego Ana está convencida de que el certificado que tiene en su poder es sin duda el de Carmen.
b) Ahora que Ana está convencida, redacta el mensaje y lo encripta con el certificado de Carmen y lo firma con su clave privada. Lo envía a Carmen.
C) El mensaje llega a Carmen y lo primero con lo que se topa es la firma. El gestor de correo busca la clave pública perteneciente a dicho correo electrónico accediendo posiblemente al repositorio del CA emisor y el nombre y apellidos de Ana. Carmen no se fia de que sea Ana, pero el certificado que ha encontrado efectivamente tipifica dicho correo electrónico y dichas credenciales, y está emitido y firmado por la FNMT (se verifica la firma de la FNMT, que a su vez verifica el certificado de Ana). Cuando está seguro del certificado de Ana, desencripta la firma con él, dado que la clave pública de Ana desencripta el hash que fue encriptado con la clave privada de esta. Carmen verifica la firma y con su clave privada desencripta el mensaje y lo lee.