Hace unos par de meses, por fin tuve tiempo para realizar la integración del plugin de twitter que hice en 747mx.com. Para mi desgracia el servidor compartido no estaba muy actualizado y para que me funcionara tuve que añadir como parámetro, en las propiedades de la función cURL, el certificado de la Autoridad Certificadora. En este caso la CA de VeriSign.

Y este ejemplo me viene al pelo para intentar explicar brevemente como funciona los certificados digitales y es que, como en la vida misma, todo está basado en relaciones de confianza.

Los fundamentos…

La firma y la encriptación utilizando los certificados digitales se fundamentan en cifrado asimétrico en el que se utilizan dos claves. Una clave es pública y puede navegar sin problemas, bien por la red, en un correo electrónico, o embebida en un documento firmado por el usuario. La otra clave es privada y es la que sólo está en posesión del dueño. Por esa última razón las dos claves se deberían generar en el dispositivo del usuario, y no por ejemplo en el servidor en una aplicación web.

Con las dos parejas de claves se pueden hacer:

1)  Firmar un “mensaje” con la clave privada y comprobar esa firma con la clave pública. Se calcula un resumen criptográfico (hash) del mensaje y el emisor con su clave privada firma este hash. El receptor vuelve a calcular el hash del mensaje y lo compara con el valor obtenido de firma con la clave pública del emisor.

Así, con la firma se comprueban dos cosas:

– La “integridad” ya que el mensaje no ha sido modificado desde que se ha enviado (no coincidirían los hash).

– El “no repudio” ya que sólo ha podido emitir la firma el poseedor de la clave privada que corresponde a la clave pública.

2) Cifrar un “mensaje” con la clave pública y descifrarlo con la clave privada. Solamente el poseedor de la clave privada es capaz de leer el mensaje en claro.

… la confianza …

Hasta aquí la situación es esta: dos usuarios generan sus parejas de claves y para mantener mensajes autentificados y cifrados se intercambian sus respectivas claves públicas, pero … ¿ cómo comprueban su “identidad”? ¿cómo saben que el ha generado la clave pública que tienen es quien dice ser?… Puedes caer en el peligro de lo que se llama el “ataque del hombre el medio”. Una tercera persona ‘puentea’ la comunicación entre otras dos, generado dos parejas de claves y hace de ‘proxy‘ simulando ser la primera persona para la segunda, y ser la segunda para la primera y permitiéndolo ‘escuchar’ toda la conversación.

Y es aquí donde retomo el título del post y entran en juego las relaciones de confianza… Tiene que existir algún mecanismo, que sin conocer al poseedor de la clave pública,  permita «confiar» en que es quien dice ser.

Esa confianza se puede establecer de varias maneras. O bien por anillo de confianza, o bien delegándola en una Autoridad Certificadora (y porque no, dando una vuelta de tuerca más, descasándola en una solución mixta).

Las dos se basan en firmar la clave pública de un usuario que se conoce su autenticidad. El el caso del anillo de confianza, es el usuario que conoce a la persona el que realiza la firma de la clave. En el caso de  la Autoridad Certificadora es esta la que establece los medios necesarios para certificar la autenticidad del usuario y después firma la clave publica del usuario con su clave privada. Un ejemplo de Autoridad Certificadora es la Policía Española con el DNI electrónico.

Así un tercero sólo necesita dar “confianza” y establecer como auténticas a sólo unas pocas claves públicas del anillo o en la clave de la autoridad certificadora.

Así en el caso de claves públicas de terceros, sólo serán “confiables” aquellas que estén firmadas por las que “confío”, o en todo caso por las que estén firmadas por claves que a su vez estén firmadas por claves en las que confío (disculpadme lo de “…la parte contratante de la primera parte…” 🙂 ). Se establece entonces una “cadena de confianza” en forma de árbol. Creo que el chascarrillo que lo resume es: “…los amigos de mis amigos son mis amigos…”

… y los certificados

Y es que un certificado digital, lo que viaja por la red, y que por ejemplo podemos ver en un navegador cuando comprobamos el certificado de un página https, no es más que un contenedor que contiene la clave pública, metadatos y la firma de ambos por parte de la Autoridad Certificadora. Estos metadatos incluyen los datos de la persona o la empresa para para quien ha sido emitido, las fechas de validez, la dirección donde consultar si el certificado ha sido revocado por la entidad emisora (OSCP o CRL), los datos de la entidad emisora, un número de serie, etc.

Los navegadores como el Firefox, lectores de PDF por ejemplo el Adobe Acrobat, la máquina virtual de Java (si tienes instala la JDK están en el fichero ‘cacerts’ dentro de ‘$JAVA_HOME/jre/lib/security/cacert’), PHP para utilizar la función “cURL” vienen de serie ya con los certificados de las Autoridades Certificadoras más reconocidas.

Por el hecho de venir con la instalación del programa de turno, implícitamente le das confianza a estas autoridades certificadas. Lo que no significa que las puedas dejar de dar confianza eliminado sus certificados manualmente. O que puedas dar la misma confianza a otras autoridades incluyéndolas manualmente y que a todos los efectos los certificados emitidos por esta Autoridad Certificadora tengan la misma validez.

Esto es justo lo que me ha pasado en el ejemplo con el que empezaba el post. Para poder establecer la comunicación ssl con el api de twitter tuve que “darle confianza” a la CA e incluir su certificado en las opciones de la función cURL.

Y es que como ya he dicho antes, como en la vida misma, todo es cuestión de confianza…

Espero que os sirva.

M.E.