UNIDAD 9: Protocolos Criptográficos

Un protocolo de seguridad (también llamado protocolo criptográfico o protocolo de cifrado) es un protocolo abstracto o concreto que realiza funciones relacionadas con la seguridad, aplicando métodos criptográficos.

Un protocolo describe la forma en que un algoritmo debe usarse. Un protocolo lo suficientemente detallado incluye detalles acerca de las estructuras de datos y representaciones, punto en el cual puede usarse para implementar versiones interoperables múltiples de un programa.

Los protocolos criptográficos se usan ampliamente para transporte de datos seguros a nivel de aplicación. Un protocolo criptográfico comúnmente incorpora por lo menos uno de los siguientes aspectos:

§  Establecimiento de claves

§  Autenticación de entidades

§  Cifrado simétrico y autenticación de mensajes

§  Transporte de datos en forma segura a nivel de aplicación

§  Métodos de no repudio

Por ejemplo, TransportLayer Security (TLS) es un protocolo criptográfico usado en conexiones web (HTTP) seguras. Posee un mecanismo de autenticación de entidades basado en el sistema X.509, una fase de configuración de claves, en la cual se decide una clave de cifrado simétrico mediante el uso de criptografía de clave pública, y una función de transporte de datos de nivel de aplicación. Estos tres aspectos tienen interconexiones importantes. El TLS estándar no provee apoyo para no repudio.

Hay otros tipos de protocolos criptográficos también e incluso el término mismo tiene varias interpretaciones distintas. Los protocolos criptográficos de aplicación usan a menudo uno o más métodos de acuerdo de claves, a los cuales a veces se los llama «protocolos criptográficos». De hecho, el TLS emplea el intercambio de claves de Diffie-Hellman, el cual si bien no forma parte del TLS, puede ser visto como un protocolo criptográfico por sí mismo para otras aplicaciones.

Los protocolos criptográficos pueden ser verificados formalmente en un nivel abstracto algunas veces.

9.1 Técnicas generales

Redundancia

El primer principio es que todos los mensajes encriptados deben contener redundancia, es decir, información no necesaria para entender el mensaje. Un ejemplo puede dejar en claro la necesidad de esto. Considere una compañía de compras por correo, El Perezoso (EP), que tiene 60,000 productos. Pensando que son muy eficientes, los programadores de EP deciden que los mensajes de pedidos deben consistir en un nombre de cliente de 16 bytes seguido de un campo de datos de 3 bytes (1 byte para la cantidad y 2 para el número de producto). Los últimos 3 bytes deben encriptarse usando una clave muy grande conocida sólo por el cliente y EP.

En un principio, esto podría parecer seguro, y en cierto sentido lo es, puesto que los intrusos pasivos no pueden descifrar los mensajes. Desgraciadamente, el sistema también tiene una falla mortal que lo vuelve inútil. Supongamos que un empleado recientemente despedido quiere vengarse de EP por haberlo cesado. Antes de irse, se lleva con él (parte de) la lista de clientes; entonces trabaja toda la noche escribiendo un programa para generar pedidos ficticios usando nombres reales de los clientes. Dado que no tiene la lista de claves, simplemente pone números aleatorios en los últimos 3 bytes y envía cientos de pedidos a EP.

Al llegar estos mensajes, la computadora de EP usa el nombre del cliente para localizar la clave y descifrar el mensaje. Para mala suerte de EP, casi cada mensaje de 3 bytes es válido, por lo que la computadora comienza a imprimir instrucciones de embarque. Aunque podría parecer extraño que un cliente ordene 837 juegos de columpios para niños, o 540 cajas de arena, en lo que a la computadora concierne el cliente bien podría estar planeando abrir una cadena de franquicias con juegos infantiles. De esta manera, un intruso activo (el ex empleado) puede causar muchísimos problemas, aun cuando no pueda entender los mensajes que genera su computadora.

Este problema puede resolverse agregando redundancia a todos los mensajes. Por ejemplo, si se extienden los mensajes de pedido a 12 bytes, de los cuales los primeros 9 deben ser ceros, entonces este ataque ya no funciona, porque el ex empleado ya no puede generar una cadena grande de mensajes válidos. La moraleja de esta historia es que todos los mensajes deben contener una cantidad considerable de redundancia para que los intrusos activos no puedan enviar basura al azar y lograr que se interprete como mensajes válidos.

Principio criptográfico 1: Los mensajes deben contener alguna redundancia

En otras palabras, al desencriptar un mensaje, el destinatario debe tener la capacidad de saber si es válido con sólo inspeccionarlo y tal vez realizando un cálculo simple. Esta redundancia es necesaria para evitar que intrusos activos envíen basura y engañen al receptor para que descifre la basura y realice algo con el “texto llano”. Sin embargo, esta misma redundancia simplifica en gran medida la violación del sistema por parte de los intrusos pasivos, por lo que aquí hay un poco de preocupación. Más aún, la redundancia nunca debe estar en la forma de n ceros al principio o al final del mensaje, debido a que al ejecutar tales mensajes a través de algunos algoritmos criptográficos los resultados son más predecibles, lo que facilita el trabajo del criptoanalista. Un polinomio CRC es mejor que una serie de 0s puesto que el receptor puede verificarlo fácilmente, pero implica más trabajo para el criptoanalista. Un método aún mejor es utilizar un hash criptográfico, concepto que exploraremos más adelante.

Actualización

El segundo principio criptográfico es que se deben tomar medidas para asegurar que cada mensaje recibido se verifique a fin de saber si está actualizado, es decir, que se haya enviado muy recientemente. Esta medida es necesaria para evitar que intrusos activos reproduzcan mensajes antiguos.

Si no se tomaran tales medidas, el ex empleado podría intervenir la línea telefónica de EP

y simplemente continuar repitiendo los mensajes válidos enviados previamente. En otras palabras, tenemos:

Principio criptográfico 2: Es necesario algún método para frustrar los ataques de repetición. Una de tales medidas es incluir en cada mensaje una marca de tiempo válida durante, digamos, 10 segundos. El receptor puede entonces guardar los mensajes unos 10 segundos, para compararlos con los mensajes nuevos que lleguen y filtrar los duplicados. Los mensajes con una antigüedad mayor a 10 segundos pueden descartarse, dado que todas las repeticiones enviadas más de 10 segundos después también se rechazarán como demasiado viejas. Más adelante estudiaremos algunas medidas diferentes a las marcas de tiempo.

Cifrados por sustitución

En un cifrado por sustitución, cada letra o grupo de letras se reemplazan por otra letra o grupo de letras para disfrazarla. Uno de los cifrados más viejos conocidos es el cifrado de César, atribuido a Julio César. En este método, a se vuelve D, b se vuelve E, c se vuelve F, … , y z se vuelve C. Por ejemplo, ataque se vuelve DWDTXH. En los ejemplos, el texto llano se presentará en minúsculas y el texto cifrado en mayúsculas.

La siguiente mejora es hacer que cada uno de los símbolos del texto llano, digamos las 26 letras del abecedario (no incluimos la ñ) inglés, tengan una correspondencia con alguna otra letra.

Por ejemplo,

texto llano: a b c d e f g h i j k l m n o p q r s t u v w x y z

texto cifrado: Q W E R T Y U I O P A S D F G H J K L Z X C V B N M

El sistema general de sustitución de símbolo por símbolo se llama sustitución monoalfabética, siendo la clave la cadena de 26 letras correspondiente al alfabeto completo. Para la clave anterior, el texto llano ataque se transformaría en el texto cifrado QZQJXT.

 Cifrados por transposición

Los cifrados por sustitución conservan el orden de los símbolos de texto llano, pero los disfrazan.

Los cifrados por transposición, en contraste, reordenan las letras pero no las disfrazan. En la figura 8-3 se presenta un cifrado de transposición común, la transposición columnar. La clave del cifrado es una palabra o frase que no contiene letras repetidas. En este ejemplo, la clave es MEGABUCK.

El propósito de la clave es numerar las columnas, estando la columna 1 bajo la letra clave más cercana al inicio del alfabeto, y así sucesivamente. El texto llano se escribe horizontalmente, en filas, las cuales se rellenan para completar la matriz si es necesario. El texto cifrado se lee por columnas, comenzando por la columna cuya letra clave es la más baja.

 Rellenos de una sola vez

La construcción de un cifrado inviolable en realidad es bastante sencilla; la técnica se conoce desde hace décadas. Primero se escoge una cadena de bits al azar como clave. Luego se convierte el texto llano en una cadena de bits, por ejemplo usando su representación ASCII. Por último, se calcula el OR EXCLUSIVO de estas dos cadenas, bit por bit. El texto cifrado resultante no puede descifrarse, porque en una muestra suficientemente grande de texto cifrado cada letra aparecerá con la misma frecuencia, lo mismo que cada digrama y trigrama, y así sucesivamente. Este método, conocido como relleno de una sola vez, es inmune a todos los ataques actuales y futuros sin importar cuánta potencia computacional tenga el intruso. La razón se deriva de una teoría de la información: simplemente no hay información en el mensaje debido a que todos los textos llanos posibles de una longitud dada son parecidos.

Criptografía cuántica

La criptografía cuántica se basa en el hecho de que la luz viene en pequeños paquetes llamados fotones, los cuales tienen algunas propiedades peculiares. Además, la luz puede polarizarse al pasarla a través de un filtro de polarización, un hecho bien conocido por quienes utilizan anteojos oscuros y por los fotógrafos. Si se pasa un haz de luz (es decir, un flujo de fotones) a través de un filtro polarizador, todos los fotones que emerjan de él se polarizarán en la dirección del eje del filtro (por ejemplo, el vertical). Si a continuación el haz se pasa a través de un segundo filtro polarizador, la intensidad de la luz que emerja del segundo filtro es proporcional al cuadrado del coseno del ángulo entre los ejes. Si los dos ejes son perpendiculares, no pasa ningún fotón. La orientación absoluta de los dos filtros no importa; sólo cuenta el ángulo entre sus ejes.

9.2 Privacidad en email, firmas digitales

La autenticidad de muchos documentos legales, financieros y de otros tipos se determina por la presencia o ausencia de una firma manuscrita autorizada.

Básicamente, lo que se requiere es un sistema mediante el cual una parte pueda enviar un mensaje “firmado” a otra parte de modo que:

1. El receptor pueda verificar la identidad del transmisor.

2. El transmisor no pueda repudiar (negar) después el contenido del mensaje.

3. El receptor no haya podido elaborar el mensaje él mismo.

Firmas de clave simétrica

Un enfoque de las firmas digitales sería tener una autoridad central que sepa todo y en quien todos confíen, digamos el Big Brother(BB). Cada usuario escoge entonces una clave secreta y la lleva personalmente a las oficinas del BB. Por tanto, sólo Alice y el BB conocen la clave secreta de Alice, KA, etcétera.

Cuando Alice quiere enviar un mensaje de texto llano firmado, P, a su banquero, Bob, genera KA(B, RA, t, P) donde B es la identidad de Bob, RA es un número aleatorio elegido por Alice, t es una marca de tiempo para asegurar que el mensaje sea reciente, y KA(B, RA, t, P) es el mensaje encriptado con su clave, KA. A continuación lo envía como se muestra en la figura 8-18. El BB ve que el mensaje es de Alice, lo desencripta, y envía un mensaje a Bob como se muestra. El mensaje a Bob contiene el texto llano del mensaje de Alice y también el mensaje firmado KBB(A, t, P). Ahora, Bob atiende la solicitud de Alice.

Firmas de clave pública

Un problema estructural del uso de la criptografía de clave simétrica para las firmas digitales es que todos tienen que confiar en el Big Brother. Es más, el Big Brother lee todos los mensajes firmados. Los candidatos más lógicos para operar el servidor del Big Brother son el gobierno, los bancos, los contadores y los abogados. Por desgracia, ninguna de estas organizaciones inspira confianza completa a todos los ciudadanos. Por tanto, sería bueno si la firma de documentos no requiriese una autoridad confiable.

Afortunadamente, la criptografía de clave pública puede hacer una contribución importante

aquí. Supongamos que los algoritmos públicos de encriptación y desencriptación tienen la propiedad de que E(D(P)) = P además de la propiedad normal de D(E(P)) = P. (El RSA tiene esta propiedad, por lo que el supuesto es razonable.) Suponiendo que éste es el caso, Alice puede enviar un mensaje de texto llano firmado, P, a Bob, transmitiendo EB(DA(P)). Observe que Alice conoce su propia clave (privada), DA, así como la clave pública de Bob, EB, por lo que Alice puede elaborar este mensaje.

Cuando Bob recibe el mensaje, lo transforma usando su clave privada, como es normal, produciendo DA(P), como se muestra en la figura 8-19. Bob almacena este texto en un lugar seguro y lo descifra usando EA para obtener el texto llano original.

9.3 Kerberos

Kerberos es un protocolo de autenticación de redes de ordenador creado por Gerard FillipKominek que permite a dos computadores en una red insegura demostrar su identidad mutuamente de manera segura. Sus diseñadores se concentraron primeramente en un modelo de cliente-servidor, y brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro. Los mensajes de autenticación están protegidos para evitar eavesdropping y ataques de Replay.

Kerberos se basa en criptografía de clave simétrica y requiere un tercero de confianza. Además, existen extensiones del protocolo para poder utilizar criptografía de clave asimétrica.

Kerberos fue creado por el MIT como una solución para estos problemas de seguridad de la red. El protocolo de Kerberos usa una criptografía fuerte con el propósito de que un cliente pueda demostrar su identidad a un servidor (y viceversa) a través de una conexión de red insegura. Después de que un cliente/servidor han conseguido a través de Kerberos demostrar su identidad, también pueden cifrar todas sus comunicaciones para garantizar la privacidad y la integridad de los datos intercambiados

Como funciona.

A continuación se describe someramente el protocolo. Se usaran las siguientes abreviaturas:

• AS = Authentication Server

• TGS = Ticket Granting Server

• SS = Service Server.

En resumen el funcionamiento es el siguiente: el cliente se autentica a sí mismo contra el AS, así demuestra al TGS que está autorizado para recibir un ticket de servicio (y lo recibe) y ya puede demostrar al SS que ha sido aprobado para hacer uso del servicio kerberizado.

En más detalle:

1. Un usuario ingresa su nombre de usuario y password en el cliente

2. El cliente genera una clave hash a partir del password y la usará como la clave secreta del cliente.

3. El cliente envía un mensaje en texto plano al AS solicitando servicio en nombre del usuario. Nota: ni la clave secreta ni el password son enviados, solo la petición del servicio.

4. El AS comprueba si el cliente está en su base de datos. Si es así, el AS genera la clave secreta utilizando la función hash con la password del cliente encontrada en su base de datos. Entonces envía dos mensajes al cliente:

   1. Mensaje A: Client/TGS sessionkey cifrada usando la clave secreta del usuario

   2. Mensaje B: Ticket-Granting Ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de validez y el Client/TGS sessionkey) cifrado usando la clave secreta del TGS.

5. Una vez que el cliente ha recibido los mensajes, descifra el mensaje A para obtener el client/TGS sessionkey. Esta sessionkey se usa para las posteriores comunicaciones con el TGS. (El cliente no puede descifrar el mensaje B pues para cifrar éste se ha usado la clave del TGS). En este momento el cliente ya se puede autenticar contra el TGS.

6. Entonces el cliente envía los siguientes mensajes al TGS:

   1. Mensaje C: Compuesto del Ticket-Granting Ticket del mensaje B y el ID del servicio solicitado.

   2. Mensaje D: Autenticador (compuesto por el ID de cliente y una marca de tiempo), cifrado usando el client/TGS sessionkey.

7. Cuando recibe los mensajes anteriores, el TGS descifra el mensaje D (autenticador) usando el client/TGS sessionkey y envía los siguientes mensajes al cliente:

   1. Mensaje E: Client-to-server ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de validez y una Client/Server sessionkey) cifrado usando la clave secreta del servicio.

   2. Mensaje F: Client/server session key cifrada usando el client/TGS session key.

8. Cuando el cliente recibe los mensajes E y F, ya tiene suficiente información para autenticarse contra el SS. El cliente se conecta al SS y envía los siguientes mensajes:

   1. Mensaje E del paso anterior.

   2. Mensaje G: un nuevo Autenticador que incluye el ID de cliente, una marca de tiempo y que está cifrado usando el client/server sessionkey.

9. El SS descifra el ticket usando su propia clave secreta y envía el siguiente mensaje al cliente para confirmar su identidad:

   1. Mensaje H: la marca de tiempo encontrada en el último Autenticador recibido del cliente más uno, cifrado el client/server sessionkey.

10. El cliente descifra la confirmación usando el client/server sessionkey y chequea si la marca de tiempo está correctamente actualizada. Si esto es así, el cliente confiará en el servidor y podrá comenzar a usar el servicio que este ofrece.

El servidor provee del servicio al cliente.

Ventaja de Kerberos

Los servicios de redes más convencionales usan esquemas de autenticación basados en contraseñas. Tales esquemas requieren que cuando un usuario necesita una autenticación en un servidor de red, debe proporcionar un nombre de usuario y una contraseña. Lamentablemente, la información de autenticación para muchos servicios se transmite sin estar encriptada. Para que un esquema de este tipo sea seguro, la red tiene que estar inaccesible a usuarios externos, y todos los usuarios de la red deben ser de confianza.

 Aún en este caso, una vez que la red se conecte a la Internet, ya no puede asumir que la red es segura. Cualquier intruso del sistema con acceso a la red y un analizador de paquetes puede interceptar cualquier contraseña enviada de este modo, comprometiendo las cuentas de usuarios y la integridad de toda la infraestructura de seguridad.

El primer objetivo de Kerberos es el de eliminar la transmisión a través de la red de información de autenticación. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseñas en su red.

Desventajas .

A pesar de que Kerberos elimina una amenaza de seguridad común, puede ser difícil de implementar por una variedad de razones:

• La migración de contraseñas de usuarios desde una base de datos de contraseñas estándar UNIX, tal como /etc/passwd o/etc/shadow, a una base de datos de contraseñas Kerberos puede ser tediosa y no hay un mecanismo rápido para realizar esta tarea. Para más información, refiérase a la pregunta número 2.23 en el la sección FAQ de Kerberos en: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

• Kerberos es sólo parcialmente compatible con los PluggableAuthentication Modules (PAM) usados por la mayoría de los servidores Red Hat Enterprise Linux.

• Kerberos presupone que cada usuario es de confianza pero que está utilizando una máquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseñas no encriptadas sean enviadas a través de la red. Sin embargo, si cualquier otro usuario aparte del usuario adecuado, tiene acceso a la máquina que emite tickets usados para la autenticación — llamadoCentro de distribución de llaves (KDC) —, el sistema de autenticación de Kerberos completo está en riesgo.

• Para que una aplicación use Kerberos, el código debe ser modificado para hacer las llamadas apropiadas a las librerías de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradas kerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programación, debido al tamaño de la aplicación o su diseño. Para otras aplicaciones incompatibles, los cambios se deben realizar en el modo en que el servidor de red y sus clientes se comunican; de nuevo, esto puede suponer bastante programación. En general, las aplicaciones de código cerrado que no tienen soporte de Kerberos son usualmente las más problemáticas.

• Finalmente, si decide usar Kerberos en su red, debe darse cuenta de que es una elección de todo o nada. Si decide usar Kerberos en su red, debe recordar que si se transmite cualquier contraseña a un servicio que no usa Kerberos para autenticar, se corre el riesgo de que el paquete pueda ser interceptado. Así, su red no obtendrá ningún beneficio de usar Kerberos. Para asegurar su red con Kerberos, sólo debe utilizar las versiones kerberizadas (que funcionen con Kerberos) de todas las aplicaciones cliente/servidor que envien contraseñas sin encriptar o no utilizar ninguna de estas aplicaciones en la red.

9.4 Efectivo Digital

El efectivo digital conocido también como e-money, efectivo electrónico, moneda electrónica, dinero digital, dinero electrónico o moneda digital es aquel que se intercambia sólo de manera electrónica. Esto requiere la utilización de una red de ordenadores,  Internet y sistemas de valores (Representación paso a paso de cantidades.) digitalmente almacenados. Las transferencias electrónicas de fondos (EFT) y los depósitos directos son ejemplos de dinero electrónico. De la misma forma, es un término colectivo para criptografía financiera y tecnologías que los permitan.

 La criptografía financiera (FC de financial cryptography) es el uso de la criptografía en aplicaciones en las pueden resultar pérdidas financieras de la subversión del sistema de mensajes.

 La atención de los criptógrafos en el campo es originaria de la labor del Dr. David Chaum que inventó la firma digital ciega. Esta especial forma de firma criptográfica permite una moneda virtual  sin que el firmante vea la moneda, y permite una forma simbólica de dinero digital que ofrece irrastreabilidad. Esta forma es a veces conocida como «Digital Cash».

Un mecanismo criptográfico ampliamente utilizado y desarrollado previamente es el cifrado de datos estándar, que se utilizan principalmente para la protección de las transferencias electrónicas de fondos. Sin embargo, es el trabajo de David Chaum el que interesó a la comunidad criptográfica sobre el potencial de los mensajes cifrados como efectivos instrumentos financieros.

 La criptografía financiera incluye los mecanismos y los algoritmos necesarios para la protección de las transferencias financieras, además de la creación de nuevas formas de dinero. Pruebas de trabajo y diversos protocolos de subasta están bajo el paraguas financiero de la criptografía financiera. Hashcash se utiliza para limitar el spam.

 Se distingue de la criptografía tradicional en que para la mayor parte de la historia, la criptografía se ha utilizado casi exclusivamente para fines militares y diplomáticos. Como parte de un modelo de negocio, FC siguió a la guía de la criptografía y sólo las ideas más simples fueron adoptadas.

 La criptografía financiera es vista a menudo con un alcance muy amplio de aplicación. Ian Grigg ve la FC en siete capas, siendo la combinación de siete disciplinas distintas: criptografía, ingeniería de software, derechos, contabilidad, gestión de los asuntos públicos, valor, y aplicaciones financieras. Esto ve a la FC como una materia interdisciplinaria.

 La criptografía financiera es, en cierta medida, organizada en torno a la reunión anual de la Asociación Internacional Criptografía Financiera, que se celebra cada año en un lugar diferente.

 Si bien el dinero electrónico ha sido un interesante problema de criptografía , hasta la fecha, el uso de dinero en efectivo digital se ha efectuado relativamente a baja escala. Uno de los pocos éxitos ha sido sistema de tarjeta Octopus en Hong Kong, que comenzó como un sistema de pago de tránsito masivo y se ha utilizado ampliamente como un sistema de dinero electrónico. Singapur también ha implementado un sistema de dinero electrónico para su sistema de transporte público (tren, autobús, etc.), que es muy similar al de Hong Kong y la tarjeta Octopus basada en el mismo tipo de tarjeta (FeliCa). Otra aplicación exitosa se encuentra en los Países Bajos, conocida como Chipknip.

 Técnicamente, el dinero electrónico o digital es una representación, o un sistema de débitos y créditos, destinado (pero no limitado a esto) al intercambio de valores en el marco de un sistema, o como un sistema independiente, pudiendo ser en línea o no. El término dinero electrónico también se utiliza para referirse al proveedor del mismo. Una divisa privada puede utilizar el oro para ofrecer una mayor seguridad, como la divisa de oro digital. Un sistema de divisas digital puede ser plenamente respaldado por el oro (como e-gold y c-gold), no respaldados en oro, o de ambos sistemas (como e-Bullion y Liberty Reserve). Además, algunas organizaciones privadas, como las Fuerzas Armadas de los Estados Unidos usan divisas privadas como el Eagle Cash.

 Muchos de los sistemas electrónicos venden sus divisas directamente al usuario final, tales como Paypal y WebMoney, pero otros sistemas, tales como e-gold, venden sólo a través de terceros como las casas de cambio de moneda digital.

 En el caso de la tarjeta Octopus en Hong Kong, se trabaja de manera similar a los depósitos bancarios. Después que tarjeta Octopus Limited recibe dinero en depósito de los usuarios, el dinero se deposita en bancos, lo cual es similar al método de las tarjetas de débito donde los bancos emisores redepositan el dinero a los bancos centrales.

Algunas divisas locales, como los sistemas de cambio local, trabajan con transacciones electrónicas. El Cyclos Software permite la creación electrónica de divisas locales. El sistema Ripple es un proyecto para desarrollar un sistema de distribución de dinero electrónico independiente de la moneda local.

Dinero electrónico anónimo fuera de línea.-Con el dinero electrónico anónimo fuera de línea (off-line) el comerciante no tiene que interactuar con el banco antes de aceptar dinero por parte del usuario. En lugar de eso puede recoger múltiples monedas gastadas por los usuarios y depositarlas posteriormente en el banco. En principio esto se puede hacer fuera de línea, es decir, el comerciante podría ir al banco con su medios de almacenamiento para intercambiar el efectivo electrónico por dinero en efectivo. No obstante, el comerciante debe asegurarse que el dinero electrónico del usuario, o bien será aceptado por el banco, o el banco será capaz de identificar y castigar a los usuarios que traten de engañar por esta vía. De esta forma, un usuario no tiene posibilidad de utilizar la misma moneda dos veces (doble gasto). Los sistemas de efectivo electrónico off-line también tienen la necesidad de protegerse contra los posibles engaños de los comerciantes, es decir, los comerciantes que deseen depositar una moneda dos veces (y luego culpar al usuario).

En criptografía el efectivo electrónico anónimo fue presentado por David Chaum. Solía hacer uso de firma digital ciega para lograr hacer imposible relacionar entre el retiro y transacciones de gastos.1 En criptografía, efectivo electrónico por lo general se refiere a dinero electrónico anónimo. Dependiendo de las propiedades de las operaciones de pago, se distingue entre efectivo electrónico en línea y fuera de línea (off-line). El primer sistema de efectivo electrónico fuera de línea fue propuesto por Chaum y Naor.2 Al igual que el primer sistema en línea, se basa en firma digital ciega RSA.

9.5 Sistema de archivos criptográficos

Protocolos Criptográficos

 Protocolo Criptográfico es un protocolo (es decir un conjunto bien definido de etapas, Implicando a dos o más partes y acordado por ellas, designado para realizar una tarea específica) que utiliza como herramienta algún algoritmo criptográfico. Existe una amplia variedad de protocolos criptográficos, que dan respuesta a diferentes objetivos. Se trata de un tema muy amplio y en rápido crecimiento.

 Los protocolos criptográficos son:

 1. Protocolos de Autentificación de Usuario: Permiten garantizar que el remitente de un mensaje o el usuario con el que establecemos comunicación es realmente quien pretende ser.

2. Protocolos de Autentificación del Mensaje: Garantizan que el mensaje enviado no ha sido substituido por otro ni alterado (integridad del mensaje).

 3. Distribución de claves: Un problema importante en Criptografía de clave privada es el de la creación y transporte de las claves a utilizar por cada par de usuarios. En Cuanto a las claves de un sistema de clave pública, la problemática de su distribución es distinta (no es necesario el secreto), demandando protocolos específicos.

 4. Protocolos para Compartir Secretos: Su objetivo es distribuir un cierto secreto (por Ejemplo la clave para abrir una caja fuerte), entre un conjunto P de participantes, de forma que ciertos subconjuntos prefijados de P puedan, uniendo sus participaciones, recuperar dicho secreto.

 5. Pruebas de Conocimiento Cero: Permiten a un individuo convencer a otro de que posee una cierta información, sin revelarle nada sobre el contenido de la misma.

 6. Transacciones Electrónicas Seguras: Permiten realizar de manera electrónica segura Las operaciones bancarias habituales, firma electrónica de contratos, etc.

 7. Compromiso de bit: Permiten a una parte A comprometerse con una elección (un Bit o más generalmente una serie de bits) sin revelar tal elección hasta un momento posterior. El protocolo garantiza a otra parte B que A no cambia su elección.

 8. Transferencias Transcordadas: Permiten a una parte A enviar a otra B un mensaje o secreto entre dos posibles. A no conoce cuál de los dos ha recibido realmente B.

9. Elecciones Electrónicas: Permiten realizar un proceso electoral electrónicamente, garantizando la deseable privacidad de cada votante y la imposibilidad de fraude.

 10. Jugar al Póker por Internet: Posibilita a dos personas, físicamente separadas, mantener una partida de póker (o similar: cara o cruz, chinos, etc.), comunicándose por correo electrónico, teléfono, etc., garantizando la imposibilidad de hacer trampa.

 Distribución de Llaves

 En una tal red, cada par de usuarios A, B necesitan eventualmente una clave KAB para crear un canal privado virtual entre ambos. Una tal llave no puede ser enviada por la propia red de comunicaciones (por hipótesis insegura), necesitándose pues un canal alternativo. Si el número de usuarios es elevado el problema crece exponencialmente. tal clave KAB debe ser cambiada periódicamente (de hecho suele ser una clave de sesión utilizada solo para una comunicación).

Nos ocuparemos aquí únicamente de protocolos para la creación o acuerdo y el transporte de llaves. Señalemos que existen métodos para resolver el problema que no implican el uso de la Criptografía de Clave Pública consideraremos sin embargo únicamente los basados en ella y en concreto dos aspectos:

 1. Distribución de las llaves publicas

2. Uso del sistema de clave pública para crear y/o transportar llaves privadas.

 Distribución de las llaves publicas

En un sistema de clave pública, por la propia naturaleza de esta, no es necesario ocultar dichas llaves. Al contrario, deben estar accesibles para cualquiera que desee utilizarlas para comunicar con el propietario de las mismas. Existe, sin embargo, el riesgo de la Imperforación: un adversario C puede hacer creer a que su llave pública KC es la llave pública de B. Consideremos cuatro esquemas posibles de distribución:

 1. Anuncio público: Cada participante difunde su llave al resto. El riesgo de impersonacion es grande.

 2. Directorio público: Mantenido por una cierta autoridad, con entradas (IA,KA) y acceso libre (solo para lectura). El usuario A registra su llave en persona o mediante comunicación autorizada. Ello, en principio, elimina el riesgo de la impersonacion. Sin embargo, un adversario que gane el control del directorio puede fabricar falsas llaves públicas.

 3. Autoridad pública: Similar al anterior, pero los usuarios no tienen acceso directo al directorio. Si A desea conocer la llave de B, debe formular una petición expresa a la autoridad que mantiene el directorio.

 4. Autoridad Certificadora: La autoridad expide a cada usuario A un certificado de su llave pública. El usuario A puede enviar a B dicho certificado y este puede comprobar (utilizando la llave pública de la autoridad).

Establecimiento de llaves

Definición 1.1. Dos usuarios A, B pueden establecer una llave KAB, compartida por ambos, por dos métodos:

 • Acuerdo de llaves (key agreement): la llave es derivada por las partes como función de información suministrada por ambas. En principio ninguna parte puede predeterminar el valor de dicha llave.

 • Transporte de llaves: Una parte crea la llave y la transfiere seguramente a la otra (alternativamente es una autoridad o tercera parte quien la crea y transfiere a ambos).

 1. Implícita: Una parte tiene la seguridad de que solo la otra puede tener acceso a dicha llave.

 2. Explicita: Se tiene una confirmación de que la segunda parte ha recibido correctamente la llave.

Veamos como los sistemas de llave pública permiten dar solución a estos problemas.

 • Acuerdo de llaves

Consideraremos varios protocolos basados en un mismo contexto general:

Sean dos conjuntos G,H y una función F : H×G −! G, h, g −! F(h, g), verificando:

1. Conmutatividad: F(hA, F(hB, g)) = F(hB, F(hA, g))

2. F(−, g) es una función de una vía

3. A,B comparten un elemento g 2 G.

Ejemplo 1.2. (Logaritmo Discreto): Tomar G = Z/pZ, H = {1, 2, . . . , p − 2}, g 2 G, F(h, g) _ gh (mod p).

 Protocolo 1 (Diffie-Hellman)

Algoritmo 1.3.

1. A elige rA 2 H y calcula y envía a B, KTA = F(rA, g)

2. B elige rB 2 H y calcula y envía a A, KTB = F(rB, g)

3. Llave común: KAB = F(rA, F(rB, g)) = F(rB, F(rA, g))

Protocolo 2

A diferencia del de Diffie-Helman proporciona autentificación (implícita) de los participantes.

Requerimientos previos:

1. Cada participante X ha seleccionado hX 2 H y adoptado como llave pública de acuerdo pX = F(hX, g).

2. Los demás participantes tienen acceso a copia autentificada de pX.

Algoritmo 1.4.

1. A computa KAB = F(hA, pB).

2. B computa KAB = F(hB, pA).

 Protocolo 3 (ElGamal)

Requerimientos previos:

1. B ha seleccionado hB 2 H y construido la llave pública de acuerdo pB = F(hB, g).

2. A tiene acceso a copia autentificada de pB.

Algoritmo 1.5.

1. A genera aleatoriamente r 2 H y calcula y envía a B, F(r, g)

2. A y B computan KAB = F(r, pB) = F(r, F(hB, g)) = F(hB, F(r, g)).

Se tiene una autentificación implícita de B por parte de A. En cambio B no tiene garantizado con quien ha establecido la llave.

 Transporte de Llaves

Estos protocolos permiten transferir una llave K elegida por A a B, el cual posee un sistema de llave pública.

 Protocolo en un paso

Requerimientos previos:

1. B posee llaves de sistema público (CB,DB).

2. A tiene acceso a copia autentificada de CB.

3. TP parámetro temporal

Algoritmo 1.6.

1. A calcula y envía a B, KTA = CB(IA,K, TP)

2. B descifra, verifica TP y asocia K al usuario A.

 Protocolo de Needham-Schroeder (3 pasos)

 Transfiere dos llaves secretas KA,KB entre A y B.

Algoritmo 1.7.

1. A elige un número aleatorio rA y calcula y envía a B, C1 = CB(IA,KA, rA)

2. B descifra, obtiene rA, elige otro rB aleatorio y envía al usuario A, C2 = CA(KB, rA, rB)

3. A envía C3 = CB(rB) a B.

4. Confirmación de A: Comprueba rA es correcto con lo que autentifica a B y confirma que ha recibido KB.

5. Confirmación de B: Verifica que rB es correcto, con lo que autentifica a A y confirma la recepción de llave.

 Protocolo X.509 (2 pasos)

Requerimientos previos:

1. Cada participante tiene un sistema público de cifrado (CX,DX) y de firma digital

(SX, VX).

2. A tiene acceso a copia autentificada de CB.

Algoritmo 1.8.

1. A calcula y envía a B,

CertA,MA = (TP, rA, IB,CB(K)), SA(MA) con CertA certificado de la firma de A, TP parámetro temporal, rA número aleatorio.

2. B verifica la autenticidad de CertA, y descifra SA(MA), con VA. Comprueba entonces IB, TP, rA y acepta la autenticidad de A. Finalmente descifra y guarda K.

 Esquemas para Compartir Secretos

 Los Protocolos o Esquemas para compartir secretos tratan de resolver el siguiente problema: dado un secreto, repartir unos fragmentos de información entre varias personas, de modo que ciertas agrupaciones de estas personas puedan recuperar el secreto, pero las restantes agrupaciones no sean capaces de obtenerlo.

 Definición 2.1. Se dice que un esquema es Perfecto para realizar una estructura de acceso, cuando se satisfacen las dos propiedades siguientes:

 1. Si un subconjunto autorizado reúne sus participaciones, entonces puede determinar el valor del secreto K.

 2. Si un subconjunto no está autorizado, entonces no puede determinar ninguna información  acerca de K.

 Definición 2.2. Se denomina base de una estructura de acceso T  y se denota por T0, al subconjunto de T formado por todas aquellas agrupaciones minimales.

Ejemplo 2.3. En los esquemas umbral 􀀀0 está formado por los conjuntos con exactamente t participantes. En el ejemplo anterior del banco t = 3.

 Modelo general de esquema para compartir secretos

Definición 2.4. Un esquema se representa como un conjunto de reglas de distribución, esto es aplicaciones: f : P [ {D} −! S [ K que satisfacen f(D) 2 K y f(Pi) 2 S para 1 _ i _ l, donde f(D) = K es el secreto a compartir y f(Pi) = si es la participación que recibe Pi.

Un tal conjunto de reglas configuran un Esquema que soluciona el problema planteado. Diremos, entonces, que el esquema realiza la estructura de acceso 􀀀. Si para cada secreto K 2 K, consideramos el conjunto de reglas JK = {f 2 J /f(D) = K}, cuando el gestor del esquema quiera repartir dicho K, tomar’ a aleatoriamente una regla de JK para distribuir las participaciones.

Definición 2.5. Un esquema para compartir secretos se denomina lineal si la suma de participaciones correspondientes a dos secretos s, s0 permite reconstruir el secreto s + s0.

La realización explicita de un esquema dado ha recibido diferentes respuestas, basadas en enfoques y técnicas diversas: teoría de grafos, interpolación de polinomios, geometría afín y euclidea, códigos correctores de errores, etc. Veamos alguna de estas construcciones, todas ellas lineales.

 Esquema de Shamir

Shamir resolvió el problema de un (l, t)-esquema umbral mediante el siguiente protocolo:

 Dados l y t _ l, enteros no negativos y un secreto K 2 {0, . . . , s − 1}.

Algoritmo 2.6.

• Se toma un primo p _ max{s, l + 1}.

• Se escogen aleatoria e independientemente a1, . . . , at−1 2 Z/pZ

• Se construye el polinomio de grado t − 1, q(x) = K + Pt−1 i=1 aixi

• Se distribuye el secreto en las participaciones si = q(i) 2 Z/pZ, i = 1, . . . , l que se reparten entre los miembros del colectivo.

Mediante el Teorema de Interpolación de Lagrange, t personas del colectivo de participantes podrían recuperar el polinomio q(x), puesto que conocen las imágenes de t puntos, y de ahí su término independiente, que es el secreto. Ahora bien, t−1 personas no obtendrían información adicional sobre la que ya tenían, ya que cualquier termino independiente sería compatible con la construcción.

 Esquema mediante Circuitos monótonos

En 1987, Ito, Saito y Nishizeki dieron una construcción para resolver el problema general de compartir secretos, que demuestra que siempre existe un esquema perfecto que realiza cualquier estructura de acceso.

 Supongamos que tenemos un circuito booleano con l entradas, x1, . . . , xl, correspondientes a los l participantes P1, . . . , Pl en el esquema y una salida y. El circuito consiste en puertas “O” y puertas “Y”, pero ninguna “NO”.

Si especificamos valores booleanos para las l entradas, podemos definir B(x1, . . . , xl) = {Pi : xi = 1}, es decir, el subconjunto de P correspondiente a las entradas verdaderas. Sea 􀀀G = {B(x1, . . . , xl) : G(x1, . . . , xl) = 1} donde G(x1, . . . , xl) denota la salida y del circuito dada por las entradas x1, . . . , xl.

Si 􀀀0 _ 2P, es fácil construir un circuito monótono G tal que 􀀀G = 􀀀0. Una forma es, dada 􀀀0 la base de una estructura de acceso, considerar la formula booleana:

_A2􀀀0 ( ^ Pi2A Pi)

Si S = Z/mZ, se reparten entonces participaciones entre los integrantes del esquema. Para ello se asignan iterativamente valores f(l) a cada arista l del circuito, comenzando por la salida y. A cada participante Pi se le da como participación la lista de todos los valores f(l), 8l con input xi.

El algoritmo es el siguiente:

Algoritmo 2.7.

1. f(l) = s

2. Sea p puerta para la cual la arista de salida tiene valor asignado f(lsal), pero las aristas de entrada no.

3. Si p es de tipo “O”, se define, para toda entrada lent, f(lent) = f(lsal).

4. Si p es de tipo “Y”, con entradas l1, . . . , lt, se eligen arbitrariamente y1, . . . , yt−1 2 Z/mZ, y se define f(li) = yi, i = 1, 2, . . . t − 1 y f(lt) = f(lsal) – P yi (mod m).

En la figura se ejemplifica el caso de l = 4, 􀀀0 = {{P1, P2, P4}, {P1, P3, P4}, {P2, P3}}, m = 6 y s = 3.

La participación de P1 es entonces (5, 1), la de P2, (2, 0), la de P3, (3, 3) y la de P4, (2, 5).

9.6 Transacciones seguras en red

 Los modernos sistemas de seguridad en transacciones a través de redes están basados en el uso de Infraestructuras de Clave Pública, basadas en un conjunto de elementos como Certificados Digitales, Criptografía simétrica y de clave pública, firmas digitales,

 El problema de la seguridad en Internet, Para que una transacción sea segura  deben cumplir cuatro requisitos principales:

 1. Autenticidad: todas las entidades participantes en la transacción deben estar perfecta y debidamente identificadas antes de comenzar la misma. Debemos estar seguros de que la persona con la que nos comunicamos es realmente quién dice ser, ya que si no podemos estar facilitando datos íntimos y/o sensibles a una persona o entidad no deseada, que puede hacer con ellos luego lo que le venga en gana

 2. Confidencialidad: debemos estar seguros de que los datos que enviamos no pueden ser leídos por otra persona distinta del destinatario final deseado, o que si ocurre esto, el espía no pueda conocer el mensaje enviado. O en su defecto, que cuando consiga obtener los datos éstos ya no le sirvan para nada. Es decir, debemos estar seguros de que ninguna persona ajena a la transacción puede tener acceso a los datos de la misma.

3. Integridad: es necesario estar seguro de que los datos que enviamos llegan íntegros, sin

Modificaciones, a su destino final.  La integridad se consigue combinando Criptografía, funciones hash y firmas digitales.

 4. No repudio: debemos estar seguros de que una vez enviado un mensaje con datos importantes o sensibles el destinatario de los mismos no pueda negar el haberlos recibido. Y en una compra on-line debe garantizarse que una vez finalizada la misma ninguna de las partes que intervienen pueda negar haber participado en ella.

  Certificados Digitales o Certificados Electrónicos

Documentos electrónicos basados en la criptografía de clave pública y en el sistema de firmas digitales. La misión principal de un Certificado Digital es garantizar con toda confianza el vínculo existente entre una persona, entidad o servidor web con una pareja de claves correspondientes a un sistema criptográfico de clave pública.

 Un Certificado Digital es un documento electrónico que contiene datos identificativos de una persona o entidad (empresa, servidor web, etc.) y la llave pública de la misma, haciéndose responsable de la autenticidad de los datos que figuran en el certificado otra persona o entidad de confianza, denominada Autoridad Certificadora.

 Los datos que figuran generalmente en un certificado son:

1. Versión: versión del estándar X.509, generalmente la 3, que es la más actual.

2. Número de serie: número identificador del certificado, único para cada certificado expedido por una AC determinada.

3. Algoritmo de firma: algoritmo criptográfico usado para la firma digital.

4. Autoridad Certificadora: datos sobre la autoridad que expide el certificado.

5. Fechas de inicio y de fin de validez del certificado. Definen el periodo de validez del mismo, que generalmente es de un año.

6. Propietario: persona o entidad vinculada al certificado. Dentro de este apartado se usan una serie de abreviaturas para establecer datos de identidad. Un ejemplo sería:

 CN nombre común del usuario

OU información varia

U organización

L ciudad

S estado (provincia)

C país

E correo electrónico

UID ID de usuario

7. Llave pública: representación de la llave pública vinculada a la persona o entidad (en hexadecimal), junto con el algoritmo criptográfico para el que es aplicable.

8. Algoritmo usado para la misma para obtener la firma digital de la Autoridad Certificadora.

9. Firma de la Autoridad Certificadora, que asegura la autenticidad del mismo.

10. Información adicional, como tipo de certificado, etc.

 El certificado Digital vincula pues indisolublemente a una persona o entidad con una llave pública, y mediante el sistema de firma digital se asegura que el certificado que recibimos es realmente de la persona que consta en el mismo. El sistema de firma digital liga un documento digital con una clave de cifrado.

El procedimiento de firma digital lo que hace es obtener un resumen de un documento o de un texto aleatorio y cifrarlo con llave privada del propietario del certificado. Cuando nos llega un certificado, y su firma digital asociada, tan sólo debemos obtener nosotros el resumen el mismo, descifrar la firma con la llave pública del remitente y comprobar que ambos resúmenes coinciden, lo que nos hace estar totalmente seguros de la autenticidad del certificado. Se firma

Un resumen del documento y no el documento mismo para evitar ataques contra el sistema de cifrado RSA (por ejemplo, encriptar un documento especialmente concebido por un pirata, con lo que éste podría llegar a obtener la llave privada) y para no hacer el proceso demasiado lento. Para obtener el resumen del documento se utilizan las funciones hash o de resumen, algoritmos criptográficos muy rápidos, de uso público e irreversibles (de un sólo sentido). Son funciones de dispersión que no usan ninguna clave, y que transforman el mensaje original en una cadena de dígitos de longitud fija (generalmente de entre 16 y 128 bits). Los procesos de validación de certificados, obtención de resúmenes, descifrados y comprobación de coincidencia se realizan por el software adecuado del navegador web o programa de seguridad particular de forma transparente al usuario, por lo que éste será informado sólo en el caso de que el certificado no sea válido.

 Emisión de Certificados Digitales

Los Certificados Digitales, como ya hemos dicho, son emitidos por las Autoridades de Certificación, entidades consideradas de confianza probada, como Verisign, Cybertrust o Nortel. Al hacerse responsables estas entidades de los certificados que emiten, dando fe de la relación existente entre los datos que figuran en un certificado y la persona o entidad que lo solicita, una de las tareas más importantes de las mismas en ejercer un control estricto sobre la exactitud y veracidad de los datos incorporados en el certificado. Para solicitar un certificado a una AC la persona o entidad interesada debe cumplir unos procedimientos previos, confeccionando un documento, denominado

Requerimiento de Certificación, en el que deben figurar los datos representativos del solicitante (nombre personal o de empresa, domicilio personal o social, dominio asociado a la empresa y al servidor seguro, etc.) Y su llave pública. También debe manifestar su voluntad de aceptar dicha llave pública y demostrar que es el propietario real de la llave privada asociada, mediante el firmado digital de un mensaje. La presentación de todos estos datos ante la Autoridad Certificadora puede acarrear problemas, al estar éstas normalmente muy distantes de los solicitantes. Para solventar esto se han creado unas entidades intermedias, conocidas como

Tipos de certificados.

 Dependiendo del uso que se vaya a dar al certificado y de qué persona o entidad lo solicita, las Autoridades Certificadoras han dividido los certificados en varios tipos; desde el punto de vista de la finalidad, los certificados electrónicos se dividen en:

 1. Certificados SSL para cliente: usados para identificar y autenticar a clientes ante servidores en comunicaciones mediante el protocolo Secure Socket Layer, y se expiden normalmente a una persona física, bien un particular, bien un empleado de una empresa.

 2. Certificados SSL para servidor: usados para identificar a un servidor ante un cliente en comunicaciones mediante el protocolo Secure Socket Layer, y se expiden generalmente a nombre de la empresa propietaria del servidor seguro o del servicio que éste va a ofrecer, vinculando también el dominio por el que se debe acceder al servidor. La presencia de éste certificado es condición imprescindible para establecer comunicaciones seguras SSL.

 3. Certificados S/MIME: usados para servicios de correo electrónico firmado y cifrado, que se expiden generalmente a una persona física. El mensaje lo firma digitalmente el remitente, lo que proporciona Autenticación, Integridad y No Rechazo. También se puede cifrar el mensaje con la llave pública del destinatario, lo que proporciona Confidencialidad al envío.

4. Certificados de firma de objetos: usados para identificar al autor de ficheros o porciones de código en cualquier lenguaje de programación que se deba ejecutar en red (Java, JavaScript, CGI, etc.). Cuando un código de éste tipo puede resultar peligroso para el sistema del usuario, el navegador lanza un aviso de alerta, en el que figurará si existe certificado que avale al código, con lo que el usuario puede elegir si confía en el autor, dejando que se ejecute el código, o si por el contrario no confía en él, con lo que el código será rechazado.

5. Certificados para AC: que identifican a las propias Autoridades Certificadoras, y es usado por el software cliente para determinar si pueden confiar en un certificado cualquiera, accediendo al certificado de la AC y comprobando que ésta es de confianza.

 Secure Socket Layer.-  SSL permite la Confidencialidad y la Autentificación en las transacciones por Internet, siendo usado principalmente en aquellas transacciones en la que se intercambian datos sensibles, como números de tarjetas de crédito o contraseñas de acceso a sistemas privados. SSL es una de las formas base para la implementación de soluciones PKI (Infraestructuras de Clave Pública). Secure Socket Layer es un sistema de protocolos de carácter general  basado en la aplicación conjunta de Criptografía Simétrica, Criptografía Asimétrica (de llave pública), certificados digitales y firmas digitales para conseguir un canal o medio seguro de comunicación a través de Internet. De los sistemas criptográficos simétricos, motor principal de la encriptación de datos transferidos en la comunicación, se aprovecha la rapidez de operación, mientras que los sistemas asimétricos se usan para el intercambio seguro de las claves simétricas, consiguiendo con ello resolver el problema de la Confidencialidad en la transmisión de datos.

SSL implementa un protocolo de negociación para establecer una comunicación segura a nivel de socked (nombre de máquina más puerto), de forma transparente al usuario y a las aplicaciones que lo usan. Actualmente es el estándar de comunicación segura en los navegadores web más importantes (protocolo HTTP), como Netscape Navigator e Internet Explorer, y se espera que pronto se saquen versiones para otras otros protocolos de la capa de Aplicación (correo, FTP, etc.). La identidad del servidor web seguro (y a veces también del usuario cliente) se consigue mediante el Certificado Digital correspondiente, del que se comprueba su validez antes de iniciar el intercambio de datos sensibles (Autenticación), mientras que de la seguridad de Integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y la comprobación de resúmenes de todos los datos enviados y recibidos. Desde el punto de vista de su implementación en los modelos de referencia OSI y TCP/IP, SSL se introduce como una especie de nivel o capa adicional, situada entre la capa de Aplicación y la capa de Transporte, sustituyendo los sockets del sistema operativo, lo que hace que sea independiente de la aplicación que lo utilice, y se implementa generalmente en el puerto 443.

 La versión más actual de SSL es la 3.0. Que usa los siguientes algoritmos

 * RSA + Triple DES de 168 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, es uno de los conjuntos más fuertes en cuanto a seguridad, ya que son posibles 3.7* 1050 claves simétricas diferentes, por lo que es muy difícil de romper. Por ahora sólo está permitido su uso en Estados Unidos, aplicándose sobre todo en transacciones bancarias.

* RSA + RC4 de 128 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, permite 3.4 * 10 38 claves simétricas diferentes que, aunque es un número inferior que el del caso anterior, da la misma fortaleza al sistema. Análogamente, en teoría sólo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementación en los navegadores más comunes, siendo usado por organismos gubernamentales, grandes empresas y entidades bancarias.

 * RSA + RC2 de 128 bits + MD5: soportado sólo por SSL 2.0, permite 3.4 * 10 38. Claves simétricas diferentes, y es de fortaleza similar a los anteriores, aunque es más lento a la hora de operar. Sólo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementación en los navegadores más comunes.

 * RSA + DES de 56 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, aunque es el caso de la versión 2.0 se suele usar MD5 en vez de SHA-1. Es un sistema menos seguro que los anteriores, permitiendo 7.2 * 10 16 claves simétricas diferentes, y es el que suelen traer por defecto los navegadores web en la actualidad (en realidad son 48 bits para clave y 8 para comprobación de errores).

 * RSA + RC4 de 40 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, ha sido el sistema más común permitido para exportaciones fuera de Estados Unidos. Permite aproximadamente 1.1 * 10 12 claves simétricas diferentes, y una velocidad de proceso muy elevada, aunque su seguridad es ya cuestionable con las técnicas de Criptoanálisis actuales.

 * RSA + RC2 de 40 bits + MD5: en todo análogo al sistema anterior, aunque de

Velocidad de proceso bastante inferior.

 * Sólo MD5: usado solamente para autentificar mensajes y descubrir ataques a la

Integridad de los mismos. Se usa cuando el navegador cliente y el servidor no tienen ningún sistema SSL común, lo que hace imposible el establecimiento de una comunicación cifrada. No es soportado por SSL 2.0, pero si por la versión 3.0.

La clave de encriptación simétrica es única y diferente para cada sesión, por lo que si la comunicación falla y se debe establecer una nueva sesión SSL, la contraseña simétrica se generará de nuevo. SSL proporciona cifrado de alto nivel de los datos intercambiados (se cifran incluso las cabeceras HTTP), autenticación del servidor (y si es necesario también del cliente) e integridad de los datos recibidos.

 Protocolos Secure Socket Layer.

Para establecer una comunicación SSL es necesario que previamente el cliente y el servidor realicen un proceso de reconocimiento mutuo y de petición de conexión que, al igual que en otros tipos de comunicaciones,

 El protocolo comienza con el saludo del cliente al servidor,

A continuación, el servidor SSL responde enviándole su Certificado Digital (con su llave pública) e informándole de su versión de SSL

 El servidor solicita al cliente su Certificado Digital, en el mensaje llamado CertificateRequest.

 El cliente debe contestar al servidor mediante el mensaje CertificateVerify, enviándole entonces su certificado.

 En este momento el cliente verifica la validez del Certificado Digital del servidor, desencriptando el resumen del mismo y comprobando su corrección, verificando que ha sido emitido por una Autoridad Certificadora de confianza

 En caso de que el servidor no tenga un Certificado X.509 v3 se puede utilizar un mensaje ServerKeyExchange para enviar la clave pública sin certificado

 El cliente la descifra con la llave pública y comprueba la coincidencia, con lo que está totalmente seguro de que el servidor es quién dice ser. Y un proceso análogo a éste, pero en sentido inverso, se requiere si es necesaria la autenticación del usuario ante el servidor. Si todo está correcto el cliente genera un número aleatorio que va a servir para calcular una clave de sesión correspondiente clave maestra, que es enviada al servidor de forma segura encriptándola asimétricamente con la llave pública del mismo que aparece en el Certificado Digital.

 Finished, consistente en que cliente y servidor se envían uno al otro una copia de todas las transacciones llevadas a cabo hasta el momento, encriptándola con la llave simétrica común. Al recibir esta copia, cada host la desencripta y la compara con el registro propio de las transacciones. Si las transacciones de los dos host coinciden significa que los datos enviados y recibidos durante todo el proceso no han sido modificados por un tercero. Se termina entonces la fase Handshake. Para empezar a transmitir datos cifrados en necesario que cliente y servidor se pongan de acuerdo respecto a la forma común de encapsular los datos que se van a intercambiar, es decir, qué formato de datos se va a usar en la transmisión cifrada. Esto se realiza mediante el Protocolo SSL Record (Protocolo de Registro SSL), que establece tres componentes para la

 1. MAC-DATA: código de autenticación del mensaje.

2. ACTUAL-DATA: datos de aplicación a transmitir.

3. PADDING-DATA: datos requeridos para rellenar el mensaje cuando se usa un sistema de cifrado en bloque.

– La autenticación y la integridad de los datos recibidos mediante el resumen de cada mensaje recibido concatenado con un número de secuencia y un número secreto establecido en el estado de conexión.

 El resultado de esta concatenación se denomina MAC, y se añade al mensaje. Con esta base, la autenticación se comprueba mediante el número secreto, compartido por el cliente y el servidor, y mediante el número de secuencia, que viaja siempre encriptado. La integridad se comprueba mediante la función hash negociada.

– La confidencialidad se asegura encriptando los bloques y sus resúmenes mediante el algoritmo simétrico y la clave correspondiente negociadas en la fase Handshake.

 Existen dos tipos posibles de encriptación:

a. Cifrado en bloque: se cifran los datos en bloques de 64 bits. Si el mensaje no es múltiplo de 64 bits se le añaden los bits de relleno necesarios para obtener un número entero de bloques completos, indicándose la adición en el formato del mensaje.

 Implementación del protocolo SSL.

Por la parte del cliente, SSL viene implementado por defecto en los navegadores Internet Explorer y Netscape Navigator, lo que permite a cualquier usuario con uno de estos navegadores poder realizar compras por Internet de forma segura sin tener que conocer el sistema a fondo ni preocuparse de instalar programas adicionales (por lo menos autenticando al servidor web y con confidencialidad e integridad asegurada en la transacción). La implementación en la parte servidora (la tienda o banco por lo general) es un poco más compleja. En primer lugar, es obligatoria la obtención de un Certificado Digital para el vendedor o para el servidor seguro, solicitándolo a una Autoridad Certificadora de prestigio reconocido, conviniendo, si es posible, que dicha autoridad sea Verisign, ya que la misma está considerada como de toda confianza por los navegadores cliente, por lo que viene activada por defecto en los navegadores cliente.

Ya con el servidor certificado, el usuario podrá realizar su compra. En el momento del pago, el vendedor obtiene el PIN de la tarjeta de crédito del cliente, la fecha de caducidad y sus datos personales (si el pago se realiza por este método), por lo que deberá disponer de algún sistema que permita el envío de estos datos a una entidad financiera capaz de realizar la transferencia bancaria necesaria para completar el pago.

 Otros protocolos seguros.- Protocolo TLS – Transport Layer Security.

Para intentar corregir las deficiencias observadas en SSL v3 se buscó un nuevo protocolo que permitiera transacciones seguras por Internet, sobre todo teniendo en cuenta que SSL es propiedad de la empresa Netscape. El resultado de esta búsqueda fue el protocolo TLS.

 1. En el paso CertificateRequest del protocolo Handshake los clientes sólo contestan con un mensaje si son SSL.

2. Las claves de sesión se calculan de forma diferente.

3. A la hora de intercambiar las claves, TLS no soporta el algoritmo simétrico Fortezza, que sí es soportado por SSL. Esto es debido a la búsqueda de un código público, ya que Fortezza es de propiedad privada.

4. TLS utiliza dos campos más en el MAC que SSL, lo que lo hace más seguro.

A pesar de mejorar SSL y de ser público, TLS no está teniendo la aceptación que se esperaba (por lo menos por ahora).

Protocolo S-HTTP.- El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticación mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicación. Se puede identificar rápidamente a una página web servida con este protocolo porque la extensión de la misma pasa a ser .shtml en vez de .HTML como las páginas normales.

Protocolo SET.- SET se basa en el uso de certificados digitales para asegurar la perfecta identificación de todas aquellas partes que intervienen en una transacción on-line basada en el uso de tarjetas de pago, y en el uso de sistemas criptográficos de clave pública para proteger el envío de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso.

 Como características principales de SET podemos destacar:

– Es un estándar abierto y multiplataforma, en el que se especifican protocolos, formatos de mensaje, certificados, etc., sin limitación alguna respecto al lenguaje de programación, sistema operativo o tipo de máquina usados.

– Su principal objetivo es la transferencia segura de números de tarjetas de crédito.

– Utiliza codificación estándar (ASN.1 y DER).

– Es independiente del medio de comunicación utilizado. Fue diseñado para su uso en Internet, pero permite la conexión a través de cualquier tipo de red siempre que se definan los interfaces adecuados. Además, el protocolo SET se puede transportar directamente mediante TCP, mediante correo electrónico basado en SMTP o MIME y mediante HTTP en páginas web.

– Utiliza estándares criptográficos reconocidos y ampliamente usados (PKCS, Certificados X.509, etc.).

– El formato de los mensajes usados está basado en el estándar PKCS-7, al igual que SSL y S-MIME.

– Se basa en el uso de la Criptografía de Clave Pública.

– Realiza una Autenticación de todas las partes participantes en la transacción usando certificados digitales.

Servidores Seguros. Se entiende por Servidor Seguro un servidor de páginas web que establece una conexión cifrada con el cliente que ha solicitado la conexión, de manera que nadie, salvo el servidor y el cliente, puedan tener acceso a la información transmitida de forma útil.