En la última entrada de David Cutanda nos dejamos por nombrar algunos de los requisitos deseables para este tipo de dispositivo en una PKI. Vamos con ellos:

• Mecanismos de autenticación y autorización para múltiples usuarios y factores: Dada la importancia y criticidad de los datos contenidos en el dispositivo, es habitual que la autenticación para el acceso al mismo no se base en un solo factor, ni se requiera de un solo usuario. Vayamos por partes, un factor es un método para validar a un usuario. Por ejemplo, un factor será una contraseña, ya que empleando únicamente una contraseña se podría acceder, por ejemplo, a una cuenta de correo electrónico. Cuando se implementan métodos de acceso basados en dos factores, se emplean dos métodos distintos, y sólo se accederá si y solo si se validan los dos factores aportados como correctos. Para ilustrar un poco esta explicación se identifican a continuación distintas clasificaciones:

• Algo que el usuario es: Huella digital, imagen de la retina, etc.
• Algo que el usuario tiene: Token, Tarjeta RFID, Teléfono móvil, etc.
• Algo que el usuario sabe: Contraseña, PIN, etc.
• Algo que el usuario hace: Reconocimiento de voz, firma, etc.

Para un uso profesional en una PKI, lo habitual es que el dispositivo HSM soporte autenticación por dos factores para permitir el acceso a las claves almacenadas en el dispositivo, habitualmente claves privadas de la CA (raíz y subordinadas); así como poder configurar que para el acceso se requiera la validación de dos usuarios simultáneos.

• Mecanismos y registros de auditoría completa: Se debe mantener registro de todas las acciones que se puedan realizar en el dispositivo. Esto es debido no solo a que la confidencialidad es importante en un entorno crítico como este, sino que también es determinante la trazabilidad, es decir, la capacidad de saber quién, cuándo y cómo realizó cualquier acción sobre los certificados de la cadena de confianza de la CA. Todos estos registros podrían ser empleados como evidencia si se produjera cualquier irregularidad en el tratamiento de las claves. Por lo tanto, de cara a control, investigación o como evidencia para emprender posibles acciones legales, se debe mantener un registro completo y seguro de actividad. A este respecto se debe registrar cualquier actividad realizada con las claves, tales como generación, archivo, respaldo, recuperación, uso, destrucción, compromiso, etc.
• Copias de seguridad de claves “segura”: El HSM deberá implementar mecanismos de backup que garanticen la seguridad de las claves almacenadas en la copia de seguridad del mismo modo que el propio HSM lo haría; la solución habitual es la más sencilla, mantener un segundo HSM como backup. De acuerdo, ¿pero cómo se realiza esa copia de forma segura? El proceso de copia habitual es el siguiente, de forma previa a realizar cualquier copia se deberá generar un certificado de backup, este certificado será el que se empleará para cifrar las copias de seguridad. El certificado de backup consiste en un par de claves asimétricas, similares a las que se emplean para cualquier certificado o firma digital. Este certificado se generará en el HSM de backup, que deberá estar configurado a tal efecto. El certificado generado se importará al HSM de producción, en el que se configurará como certificado de backup y se empleará para cifrar la copia. La propia copia, del mismo modo que la clave de backup en el intercambio inicial, se almacenará en un soporte compatible por el modelo de HSM que se trate (lo que puede ser una tarjeta, un dispositivo USB, etc.).

Como hemos comentado anteriormente, los dispositivos HSM no sólo se emplean en entornos de PKI, sino que se también se utilizan habitualmente distintos entornos con requerimientos criptográficos elevados.

Antes de finalizar esta entrada me gustaría detallar algunos ejemplos en los que, del mismo modo que en una CA, es habitual el uso de HSM:

• Sistemas de pago con tarjeta (Entorno bancario): Se suelen emplear dispositivos más simples que los empleados en el entorno de PKI, ya que se requieren menos tipos de operaciones. Se emplean habitualmente en terminales punto de venta, concretamente para cifrar el PIN de forma previa a su envío. También se emplean en servidores de verificación, en este caso para descifrar los bloques que contienen los PIN, intercambiar códigos PIN entre puntos de autorización, generación de datos a introducir en bandas magnéticas de las tarjetas, etc.
• Conexiones HTTPS/SSL: En entornos en los que se requiere una alta seguridad y se ven condicionados por elevadas cuotas de uso y tienen objetivos de optimización muy elevados; se puede considerar la utilización de dispositivos HSM como aceleradores criptográficos, ya que pueden generar claves SSL mucho más rápido y en unas condiciones de seguridad mejores que cualquier procesador (este entorno, a pesar de ser parecido, sería independiente del relacionado con un certificado digital que identificara el servicio en internet).

Con esto es todo, más sobre certificados y firma digital en próximas entradas. Muchas gracias por vuestra atención y como siempre quedo a la espera de vuestros comentarios.

Seguimos con la serie de entradas relacionada con los certificados y firma digitales. En este punto, nos vamos a centrar en una parte fundamental de la infraestructura necesaria para la generación y custodia de claves, concretamente la que suele sustentar las claves principales de la cadena de confianza de una Autoridad de Certificación (en adelante CA). Como se ha comentado a lo largo de esta serie de entradas, se trata de un entorno crítico respecto a la confidencialidad, en el que una revelación accidental de información podría ser catastrófica.

Las claves privadas de la jerarquía de certificados de una CA y más especialmente el certificado raíz son los activos más críticos de estas organizaciones. Dados estos requisitos tan altos de seguridad, este tipo de claves se suelen almacenar offline en emplazamientos seguros (Centros de Procesos de Datos, Cajas de Seguridad, etc.); y en dispositivos que ofrezcan un cifrado fuerte y sea capaz de mantener un control férreo de acceso a las claves. Para ello, lo habitual es emplear dispositivos hardware diseñados a tal efecto. Estos dispositivos se denominan HSM o “Hardware Security Module”; y aunque existen aproximaciones de infraestructura de PKI que no lo emplean, es la solución más recomendable para obtener el nivel de seguridad adecuado para el entorno que nos ocupa.

Un HSM es un dispositivo hardware que crea, gestiona y almacena claves digitales con seguridad integrada. De forma general, los HSM se implementan como un dispositivo hardware dedicado, bien como tarjeta de ampliación para un ordenador personal, hasta un sistema diseñado para tal fin; en cualquier caso, la característica principal de este hardware es que incorpora un criptoprocesador seguro. Como es de esperar, más a la vista de las necesidades de seguridad del entorno, estos dispositivos se diseñaron para mitigar los riesgos de seguridad identificados, así como para optimizar todas las operaciones criptográficas que se tengan que realizar en cualquier entorno.

En resumen, estos dispositivos se han diseñado con las siguientes finalidades principales:

• Generación segura de claves criptográficas dentro del propio dispositivo.
• Gestión y almacenamiento de claves criptográficas en el propio dispositivo.
• Manipulación de información criptográfica o sensible.
• Liberar a los servidores de aplicaciones de la carga del cómputo criptográfico.

Comencemos con un componente fundamental dentro de cualquier HSM: el criptoprocesador. Un criptoprocesador es un tipo de procesador especializado en la gestión y creación de claves criptográficas.

¿Qué diferencia a este procesador de cualquier otro? Como más de uno sabrá, se pueden generar claves criptográficas con cualquier tipo de procesador, lo que incluye cualquier procesador de cómputo general que podríamos encontrar en un ordenador personal cualquiera. Por lo tanto, ¿que nos aporta el uso de criptoprocesadores? En primer lugar, un criptoprocesador es un dispositivo de funcionalidad específica, que incluye instrucciones internas para gestión de claves criptográficas (cosa que un procesador de cómputo general no posee). Este hecho hace que sea mucho más eficiente en la generación de claves que un procesador normal, una de las ventajas más conocidas de implementar funciones en hardware.

Ahora, ¿qué es un criptoprocesador seguro? Un criptoprocesador seguro garantiza que todo el procesado de claves se genera de forma interna, por lo que en ningún momento sale del dispositivo ningún tipo de información sin cifrar. El objetivo básico de este tipo de dispositivos es asegurar que no es necesario aplicar medidas de seguridad al resto del sistema, ya que el criptoprocesador implanta medidas de seguridad que garantizan que no se libera información sensible al resto del sistema y dotando al dispositivo de resistencia a intentos de manipulación. Algunas medidas concretas de seguridad que se suelen implementar en estos dispositivos son las siguientes:

• Detección y respuesta ante manipulación.
• Placas protectoras de conductividad para evitar la captura de señales internas del dispositivo.
• Ejecución controlada que asegure que no se producen retrasos temporales que puedan liberar información secreta.
• Borrado automático del dispositivo cuando se detecta cualquier tipo de manipulación.
• Controles de ejecución de sistema operativo o aplicaciones basados en cadena de confianza, para así asegurar su autenticidad.

Gran parte de estos dispositivos se han diseñado para el uso de criptografía de clave simétrica y asimétrica. Estos en concreto, como es evidente, son los que son determinantes dentro del entorno de una PKI. ¿Qué requisitos son deseables en este dispositivo en una PKI? Veamos hoy uno de los puntos clave de estos dispositivos, el elevado nivel de seguridad lógica y física.

Esto es fácil de decir pero, ¿cómo lo medimos? Actualmente se han establecido estándares que miden los niveles de seguridad implementados en cualquier dispositivo criptográfico que combina el uso de hardware y software, como un HSM. Concretamente, el “National Institute of Standards and Technology” (NIST), desarrolló un estándar que permite establecer el nivel de seguridad ofrecido por este tipo de dispositivos. Dicho estándar se denomina “Federal Information Processing Standard” (FIPS), actualmente en su versión FIPS-2. Este es el estándar de facto en estos casos, y surge como una guía de requisitos deseables para el uso de dispositivos criptográficos para organismos gubernamentales o sujetos a normativas muy estrictas. El estándar establece cuatro niveles distintos, los cuales gradúan el nivel de seguridad del dispositivo evaluado. Se detallan a grandes rasgos los requisitos para cada uno de los niveles establecidos:

• Nivel 1: Este es el nivel que podría tener cualquier ordenador personal con una tarjeta criptográfica genérica. En este nivel únicamente se requiere el uso de un algoritmo criptográfico y una función de seguridad reconocidos; no existen requisitos de seguridad física.
• Nivel 2: De forma adicional a los requisitos establecidos por el nivel anterior, en este caso, se requerirán mecanismos de seguridad física que permitan identificar si se han realizado manipulaciones del módulo que hayan podido permitir un acceso no autorizado a las claves gestionadas en el módulo. Estos mecanismos deben ser desde sellos que se rompan cuando se accede al dispositivo que almacena las claves en claro o a los parámetros de seguridad críticos del dispositivo (parámetros que se almacenan en claro sobre los registros del criptoprocesador y que se emplean para generar las claves).
• Nivel 3: Sumado a los requisitos incluidos en el nivel 2, se requiere que el dispositivo no sólo permita detectar accesos no autorizados, sino que responda a dichos accesos, uso no autorizado o modificación del módulo. Me explico, por ejemplo, un nivel de seguridad 3 sería un dispositivo que detectara su apertura y de forma automática y borrara por ejemplo los parámetros de seguridad críticos, inutilizándolo y asegurando la confidencialidad de las claves almacenadas.
• Nivel 4: Del mismo modo que en los casos anteriores, en el nivel 4 se mantienen los requisitos de los niveles anteriores y se añaden nuevos requisitos. En este caso, aparte de requerir más capacidad de detectar intrusiones físicas, el módulo deberá detectar condiciones inadecuadas de humedad, temperatura o tensión que pudieran afectar a su funcionamiento. De este modo, se puede asegurar que se gestionarán estas contingencias y la confidencialidad de la información custodiada en el módulo.

Cualquier HSM para implementar una PKI deberá al menos tener un certificado FIPS-2, obteniendo un nivel 3. Más información respecto a este estándar puede obtenerse de http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

Espero que os haya parecido interesante. La semana que viene continuaremos con otros puntos clave de estos dispositivos tan interesantes.

Continuando con nuestra serie de Fundamentos de Certificados Digitales, en esta entrada trataremos los mecanismos de validación de certificados. Para ello plantearemos la problemática y entorno que propicia la necesidad de realizar una validación, analizaremos y entenderemos el funcionamiento de los mecanismos de validación de certificados estándar que suelen proveer las autoridades de certificación (CA), y también analizaremos el uso de estos mecanismos por los principales navegadores comerciales. Vayamos paso a paso.

Como ya hemos comentado en anteriores entradas, un certificado digital (o firma digital) tiene como principal objetivo identificar digitalmente a una persona, entidad o sistema concreto; se implementan mediante algoritmos de clave asimétrica, de modo que la clave pública puede estar al alcance de cualquiera, y se emplea para que el receptor del mensaje firmado valide la firma del mensaje recibido o para que el emisor de un mensaje cifre el mensaje con la clave pública del destinatario, de modo que únicamente éste último sea capaz de descifrarlo; por su parte la clave privada será custodiada únicamente por el propietario, y es la que certifica su identidad.

[Read more…]

Siguiendo en la línea de los anteriores posts (Fundamentos sobre certificados digitales, primera y segunda parte), continuamos hablando de firma y certificación digital. En este caso, y a mi ver, siguiendo un orden lógico para la explicación, en la entrada de hoy nos centraremos en la cadena de confianza.

Como ya se comentó en entradas anteriores de este hilo, de cara a emplear o validar un certificado o firma digital, uno de los puntos más importantes es la confiabilidad del mismo, ya que, como se comentó, cualquiera puede generar una clave asimétrica e incluir los campos que desee en el certificado. De nuevo en base a este hecho surge la necesidad de la existencia de Autoridades de Certificación (CA), quienes se encargan de emitir certificados confiables y reconocidos. Pero, ¿como sabemos que el certificado que tenemos entre las manos ha sido emitido por una de estas entidades?

Aunque se comentará en próximas entradas el formato X.509 como estándar de generación de certificados digitales, es importante destacar que, como es natural, dicho formato contiene campos para introducir los datos del emisor (issuer). Es obvio que estos campos nos pueden parecer útiles para este fin; pero del mismo modo que el resto de campos del certificado pueden ser fijados al gusto de quien lo genere, por lo que en absoluto suponen una garantía de procedencia y autenticidad del certificado digital.

Para cubrir estas necesidades surge el modelo de cadena de confianza. Este modelo establece una relación entre certificados que permite asegurar, sin duda alguna, que dicho certificado ha sido emitido por una Autoridad de Certificación. Veamos en primer lugar como se implementa este modelo.

Como algunos habrán adelantado, la solución más obvia será firmar el certificado emitido con un certificado que “represente” a la CA. De este modo, si el certificado que firma es confiable, tenemos total certeza de que el certificado ha sido emitido por una CA, y por tanto quien lo emplea debería ser quien dice ser (siempre y cuando no se vulnere su clave privada, en la próxima entrada veremos de qué mecanismos se vale la CA para revocar y validar certificados, así como cómo dispone esta información al alcance de los usuarios finales de los mismos). Todo esto parece que suena bien, sin embargo, nos sigue dejando en el mismo punto del que partimos, ¿cómo sé que el certificado que firma el anterior es válido?

En el modelo de cadena de confianza jerárquico, las Autoridades de Certificación disponen de un certificado conocido como Certificado Raíz (Root CA), y como su nombre indica es el certificado que validará todos y cada uno de los certificados emitidos por la CA; sin embargo, este certificado no es el que firmará los certificados de suscriptor (o certificados finales), sino se empleará únicamente para firmar los denominados Certificados Subordinados (Sub-CA), y estos últimos firmarán los certificados de suscriptor (o finales). Se muestra un diagrama ejemplo del modelo jerárquico para ilustrar el funcionamiento de la cadena de confianza de certificados:

Es importante destacar que, en general, las Autoridades de Certificación emiten los certificados intermedios orientados a generar certificados de suscriptor en base a distintas tipologías, usos o unidades de negocio (por ejemplo certificados de persona física, persona jurídica, SSL, firma de código, etc.).

Sin embargo, el principal motivo de tomar esta decisión es proteger al máximo Certificado Raíz de la jerarquía. En base a los conceptos explicados en entradas anteriores, si un tercero consiguiera la clave privada de un Certificado Raíz, se comprometerían todos y cada uno de los certificados emitidos con la misma (es más sería capaz de emitir certificados en nombre de la CA). Visto de este modo, cobra sentido que los certificados finales no estén firmados con esta clave; además que en base a éste modelo jerárquico, un certificado de suscriptor firmado por el raíz no sería de suscriptor sino subordinado, con todo lo que conllevaría dar esa clave a un usuario. Este hecho propicia que se considere normalmente la clave privada del certificado raíz como la información de mayor valor y más crítica de la CA. Debido a ello, es habitual que la clave privada del certificado raíz se encuentre offline, en un dispositivo de seguridad cifrado y con medidas de alta seguridad (que también se comentarán en próximas entradas).

De cara a la validación del certificado firmado tanto por el certificado raíz como su subordinado, la CA mantiene online todas las claves públicas de su jerarquía; aunque habitualmente se suelen adjuntar al certificado de suscriptor (como se muestra en el ejemplo posterior). De modo que para validar un certificado de un suscriptor, se deberá comprobar la firma para toda la cadena de confianza de la CA emisora, quedando así clara la procedencia del mismo.

Por último, y siguiendo con la línea de ejemplos planteada en entradas anteriores, se muestra la información de la cadena de confianza del certificado SSL de www.bankia.es, que en este caso ha sido generado por VeriSign, Inc. (autoridad de certificación propiedad de Symantec).

Como se puede observar en la imagen, se describe la jerarquía de certificados de VeriSign que ha generado este certificado se suscriptor. Lo detallamos a continuación:

• Certificado Raíz: VeriSign Class 3 Public Primary Certification Authority
• Certificado Subordinado: VeriSign Class 3 Extended Validation SSL SGC CA
• Certificado de Suscriptor: www.bankia.es

El proceso de validación lo suelen realizar de forma automática los navegadores web, de modo que aunque el certificado no estuviera auto firmado (self signed), si detectara una incoherencia en la cadena de certificación consideraría el certificado no confiable y avisaría al usuario como se detalló en la entrada Fundamentos sobre Certificados Digitales (II).

A modo de curiosidad, dejo unos cuantos enlaces que os ayudarán a ver un ejemplo práctico de jerarquía de certificados, concretamente la de Verisign (Symantec):

• Listado de Certificados Raíz de Verisign: http://www.verisign.com/repository/root.html
• Descarga de certificados Raíz de Verisign: https://www.symantec.com/page.jsp?id=roots
• Listado de Certificados Subordinados de Verisign: http://www.verisign.com/support/verisign-intermediate-ca/index.html
• Jerarquía de Certificados de Verisign: http://www.verisign.com/repository/hierarchy/hierarchy.pdf

Dejo también una entrada referente al escándalo de TURKTRUST, en el que por error se firmaron dos certificados de suscriptor directamente con el certificado raíz, lo que tuvo consecuencias desastrosas: http://www.securitybydefault.com/2013/01/algunas-reflexiones-sobre-el-ultimo-ca.html

Gracias de nuevo por leernos y como siempre quedo a la espera de vuestros comentarios.

Como comentamos en la entrada Fundamentos sobre certificados digitales el protocolo SSL es un estándar de transmisión de datos seguros sobre Internet empleado en diversos protocolos de la capa de aplicación y protocolos de la capa de transporte (TCP) como medio para establecer conexiones seguras. El protocolo SSL funciona empleando certificados de clave asimétrica del mismo tipo que los expuestos con anterioridad.

Pasemos a describir cual es el funcionamiento básico de SSL, empleando un ejemplo que detalle los pasos para establecer una conexión segura HTTPS entre un cliente y un servidor web dotado de dicha capacidad.

En primer lugar, el cliente establece conexión con el servidor mediante su puerto HTTPS (de forma estándar el 443), para lo cual realiza una solicitud de inicio de sesión segura. A continuación, el servidor devuelve un certificado en formato X.509, que constituye su clave pública. Tras verificar que los datos del certificado son correctos, el cliente procede a generar una clave simétrica aleatoria, que es la que se empleará en la transmisión de datos, cifra esta clave con la clave pública del servidor y la envía al mismo. Tras la recepción, tanto el cliente como el servidor han establecido una conexión segura empleando una clave simétrica para su sesión; en caso de que se finalizara la sesión, bien por cierre de la misma o bien por timeout se desechará dicha clave y se renegociará una nueva en la siguiente conexión. A continuación se muestra un pequeño diagrama de su funcionamiento.

Una vez explicado a grandes rasgos cual es el funcionamiento del protocolo, y entendiendo que el mismo no sólo facilita confidencialidad sino que también ayuda a asegurar la identidad del sitio remoto, la verdadera duda que nos debería asaltar es la siguiente: ¿cómo sé que el certificado descargado es real y no se ha generado de forma fraudulenta?

Actualmente cualquiera puede generar un par de claves pública/privada asociadas al dominio que considere oportuno y asociarlos a SSL, de modo que podría establecer un servicio web con un certificado fraudulento imitando un servidor legítimo y así poder realizar cualquier acción maliciosa contra los clientes que, engañados, accedieran a su servicio.

Ante esta problemática aparecen las Autoridades de Certificación (CA), organismos directamente encargados de generar certificados digitales de cualquier tipo, desde firma digital hasta certificados de servidor SSL. Se trata de entidades autorizadas y reconocidas que generan certificados. En todos y cada uno de los certificados SSL (en base al protocolo X.509) se establece un emisor (issuer) que es la entidad que ha generado el certificado. Verificando el emisor, así como los certificados involucrados en la cadena de confianza se puede asegurar si el certificado lo ha emitido dicha entidad y de este modo se puede clasificar en base a la confianza que se deposita en dicha entidad. En base a este principio, si un certificado se ha emitido por una Autoridad de Certificación reconocida, se establece una cadena de confianza que asegura que dicho certificado es legítimo; es esta información la que emplean los navegadores comerciales.

Esta validación queda reflejada en el diagrama de funcionamiento de SSL en la línea discontinua (y que antes intencionadamente no se ha comentado). Profundizaremos en mayor detalle sobre el funcionamiento de las Autoridades de Certificación, formatos de certificado X.509 y cadena de confianza en próximas entradas.

Por último y para dotar a todos los curiosos que hayan leído esta entrada de un método fácil para identificar certificados no seguros en nuestras conexiones HTTPS con cualquier navegador, plantearemos dos ejemplos para distinguirlos. Utilizaremos Firefox, aunque en todos los navegadores funciona prácticamente igual.

Ejemplo de certificado reconocido: www.bankia.es

Como se puede observar en el área remarcada, aparece un candado verde con la identidad del propietario del certificado. Si pinchamos en dicha área e inspeccionamos el certificado obtendremos un resultado semejante al mostrado en la imagen siguiente, en el que se identifica el propietario del certificado, la Autoridad de Certificación emisora y su periodo de validez.

Ejemplo de Certificado no reconocido (en este caso mantendremos en secreto la identidad del sitio web):

Como se puede observar nuestro navegador, al detectar una irregularidad en el certificado nos solicita nuestro permiso explícito para aceptar dicho certificado a pesar de que sea no confiable.

Y con esto es todo. En próximas entradas del blog trataremos también verificaciones adicionales, como verificar la cadena de confianza de un certificado, saber qué protocolos de cifrado (o de generación de clave asimétrica) se emplean, el funcionamiento de una CA, etc. Es muy importante siempre que se vaya a enviar información confidencial o realizar una compra por Internet verificar en primer lugar si se establece un cifrado, y si el certificado emitido es confiable.

Espero que os haya gustado y quedo a la espera de vuestros comentarios.

Durante mi vida profesional he tenido la oportunidad de trabajar con distintas Autoridades de Certificación, así como a hacer consultoría de seguridad respecto al uso, gestión y generación de certificados digitales; como primera aportación a este blog, me gustaría poder aportaros algo de mi experiencia en este campo, así como poder introduciros en la materia.

En el mundo actual, en el que el mercado a través de Internet está en pleno apogeo, se vuelve tremendamente complicado mantener la seguridad de las transferencias de datos por la red. Dado que Internet es una red abierta y completamente heterogénea, es complicado mantener la confidencialidad e integridad de las comunicaciones, así como asegurar que el remitente o destinatario de cualquier comunicación en la red es quien dice ser.

Para tratar de resolver estos problemas aparece el certificado o firma digital. Un certificado o firma digital es un mecanismo que se emplea para proveer:

• Autenticidad: Calidad y carácter de verdadero o autorizado. Se puede asegurar de forma inequívoca la procedencia de la comunicación.
• Integridad: Inalterable, seguridad de que cuando se realiza una comunicación de datos el mensaje se mantiene inalterado durante la comunicación.
• No repudio: Cualidad de poder verificar el origen y la integridad de los datos.
• Confidencialidad: Propiedad que asegura que la información solo sea accesible por el destinatario del mensaje.

Como se puede observar, en general, el objetivo de una firma o certificado digital es muy similar que el de la firma manuscrita tradicional, sin embargo la tecnología que lo sustenta es completamente diferente, por lo que lo siguiente que deberíamos preguntarnos es: ¿cómo se implementa?

Para ello, se emplean algoritmos de cifrado de clave asimétrica (o pública); estos algoritmos funcionan mediante el uso de dos claves, una pública y una privada, que pertenecen a un mismo sujeto. Dichas claves se obtienen mediante un algoritmo, y tienen la particularidad de que, empleando un algoritmo concreto, un mensaje cifrado con una de las claves solo se podrá descifrar con la otra y viceversa; de este modo, un mensaje cifrado con la clave pública de un sujeto sólo podrá ser descifrado con la clave privada del mismo (y nunca con la pública). En general, la clave pública (como su nombre indica) debe estar al alcance de cualquiera, mientras que la clave privada debe ser custodiada únicamente por el propietario del par de claves (este punto es determinante para asegurar la funcionalidad de este sistema). Pero, ¿como permite asegurar la autenticidad, integridad, no repudio y confidencialidad este mecanismo?

Para hacer entender estos conceptos se van a plantear los siguientes ejemplos:

Ejemplo 1: Un sujeto A quiere enviar un correo electrónico firmado digitalmente a un sujeto B; para ello el sujeto A dispone de un par de claves en base a un algoritmo de clave asimétrica. Para el envío del correo firmado, el sujeto A, para firmar el correo calculará un nuevo hash del mismo (un hash consiste en una función matemática que ajusta cualquier texto a un conjunto definido de datos, en el caso que nos ocupa, se convierten al hash la cabecera y el cuerpo del correo). A continuación, el remitente procesará con el algoritmo de clave asimétrica y su clave privada dicho hash; esto constituye su firma digital. Por último se enviará el mensaje completo con cabecera, cuerpo del mensaje y firma al destinatario del mismo.

Ahora bien, ¿cómo asegura esto la autenticidad, la integridad y el no repudio de este mensaje? Cuando el destinatario recibe el mensaje, lo primero que debe hacer es verificar la firma digital del correo. Para ello, en base al funcionamiento del algoritmo de clave asimétrica, deberá emplear la clave pública del remitente para descifrar el hash del correo. Si el hash se descifra correctamente y corresponde con el resto del correo recibido se puede concluir que, en primer lugar, dicho correo ha sido enviado por quien dice ser (autenticidad), ya que en caso de que la firma no hubiera sido cifrada con la clave privada del remitente, no se podría haber descifrado con su clave pública. En segundo lugar su integridad, ya que en caso de que el mensaje hubiera sido manipulado el hash del correo no coincidiría tras descifrar el mismo; y por último el no repudio que no deja de ser la consecuencia de las dos anteriores, si la firma es correcta el destinatario emisor no podrá negar el contenido de dicho correo ni que haya sido redactado o enviado por nadie que no fuese él mismo.

Veamos a continuación un pequeño diagrama que describe las actividades detalladas en este punto.

Ejemplo 2: Pongámonos ahora en una situación diferente: el sujeto B quiere enviar un mensaje cifrado al sujeto A y quiere que éste sea leído única y exclusivamente por el sujeto A. En este caso, “B” deberá cifrar el mensaje completo empleando la clave pública de “A”, de modo que así “A” sea el único capaz de descifrar el mensaje, ya que esto lo puede hacer únicamente quien dispone de la clave privada asociada a la clave pública con la que se cifró. De este modo se asegura la confidencialidad en la transmisión.

Con estos dos ejemplos hemos ilustrado de forma básica cual es el funcionamiento más simple de la arquitectura de clave pública.

Una vez realizada esta explicación, en la próxima entrada nos centraremos en uno de los abundantes ejemplos prácticos disponibles, concretamente el protocolo SSL, empleado en transferencias de información digital segura como por ejemplo en las páginas web que emplean Secure Hyper Text Transfer Protocol (HTTPS).

Cualquier duda, comentario o petición no tenéis más que dejarla en los comentarios.